On 23.07.25 08:43, Jan Beulich wrote:
On 23.07.2025 08:34, Jürgen Groß wrote:
On 23.07.25 08:28, Jan Beulich wrote:
On 22.07.2025 02:19, Jason Andryuk wrote:
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -195,6 +195,14 @@ static void set_domain_state_info(struct
xen_domctl_get_domain
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, July 22, 2025 3:16 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Stefano Stabellini
> ; Julien Grall ; Bertrand Marquis
> ; Orzel, Michal ;
> Volodymyr Babchuk ; Andrew Cooper
> ; Anthony PERARD ;
> Roger Pau Monné ; Daniel P.
Not only domctl-op could do foreign updates to guest state, some hypercall,
like HVMOP_set_param, could also do, and they all need domctl_lock for
syncronization.
Later, we will introduce CONFIG_DOMCTL to wrap domctl.c. In order to
continue using domctl_lock when CONFIG_DOMCTL not defined, we'd lik
Since we move "!PV_SHIM_EXCLUSIVE" dependency from CONFIG_HVM, there is
a chance that a randconfig picking both PV_SHIM_EXCLUSIVE=y and HVM=y results
in hvm.c being built, but monitor.c not being built, which leaves
functions like monitor_traps(), etc, undefined, causing linking to fail.
So we move
On 2025/7/21 22:16, Roger Pau Monné wrote:
> On Wed, Jul 09, 2025 at 05:34:28AM +, Chen, Jiqian wrote:
>> On 2025/7/9 13:32, Jan Beulich wrote:
>>> On 09.07.2025 07:29, Chen, Jiqian wrote:
On 2025/7/8 22:10, Jan Beulich wrote:
> On 04.07.2025 09:07, Jiqian Chen wrote:
>> --- a/xen/
Hi,
> On 23 Jul 2025, at 08:33, Orzel, Michal wrote:
>
>
>
> On 22/07/2025 06:50, Jason Andryuk wrote:
>> On 2025-07-22 03:46, Michal Orzel wrote:
>>> Trying to boot a compressed kernel with UBSAN enabled, results in the
>>> following warning:
>>> (XEN) UBSAN: Undefined behaviour in common/dev
On 23.07.2025 08:34, Jürgen Groß wrote:
> On 23.07.25 08:28, Jan Beulich wrote:
>> On 22.07.2025 02:19, Jason Andryuk wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -195,6 +195,14 @@ static void set_domain_state_info(struct
>>> xen_domctl_get_domain_state *info,
>>>
On 23.07.25 08:25, Jan Beulich wrote:
On 22.07.2025 14:09, Jason Andryuk wrote:
On 2025-07-21 20:19, Jason Andryuk wrote:
Expose a domain's capabilities - control, hardware or xenstore - through
stable get domain state hypercall.
The xenstore domain can use this information to assign appropria
On 22/07/2025 06:50, Jason Andryuk wrote:
> On 2025-07-22 03:46, Michal Orzel wrote:
>> Trying to boot a compressed kernel with UBSAN enabled, results in the
>> following warning:
>> (XEN) UBSAN: Undefined behaviour in common/device-tree/kernel.c:21:12
>> (XEN) load of misaligned address 0a0
On 23.07.25 08:28, Jan Beulich wrote:
On 22.07.2025 02:19, Jason Andryuk wrote:
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -195,6 +195,14 @@ static void set_domain_state_info(struct
xen_domctl_get_domain_state *info,
info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
On 22.07.2025 02:19, Jason Andryuk wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -195,6 +195,14 @@ static void set_domain_state_info(struct
> xen_domctl_get_domain_state *info,
> info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
> if ( d->is_dying == DOMDYING_d
On 22.07.2025 14:09, Jason Andryuk wrote:
> On 2025-07-21 20:19, Jason Andryuk wrote:
>> Expose a domain's capabilities - control, hardware or xenstore - through
>> stable get domain state hypercall.
>>
>> The xenstore domain can use this information to assign appropriate
>> permissions on connecti
On 23.07.2025 00:51, Stewart Hildebrand wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1274,8 +1274,14 @@ map_grant_ref(
> }
>
> /*
> - * We're not translated, so we know that dfns and mfns are
> - * the same things, so the IOMMU e
On 23.07.2025 02:46, Stefano Stabellini wrote:
> On Tue, 22 Jul 2025, Jan Beulich wrote:
>> On 22.07.2025 07:04, Penny Zheng wrote:
>>> Function getdomaininfo() is not only invoked by domctl-op, but also
>>> sysctl-op,
>>> so it shall better live in domain.c, rather than domctl.c. Which is also
>>
On Mon, 21 Jul 2025, Jason Andryuk wrote:
> Expose a domain's capabilities - control, hardware or xenstore - through
> stable get domain state hypercall.
>
> The xenstore domain can use this information to assign appropriate
> permissions on connections.
>
> Repurpose the 16bit pad field for this
On Tue, 22 Jul 2025, Jan Beulich wrote:
> On 22.07.2025 07:04, Penny Zheng wrote:
> > Function getdomaininfo() is not only invoked by domctl-op, but also
> > sysctl-op,
> > so it shall better live in domain.c, rather than domctl.c. Which is also
> > applied for arch_get_domain_info(). Style correc
On 2025-07-21 20:19, Jason Andryuk wrote:
Expose a domain's capabilities - control, hardware or xenstore - through
stable get domain state hypercall.
The xenstore domain can use this information to assign appropriate
permissions on connections.
Repurpose the 16bit pad field for this purpose.
S
Stewart,
> EXT email: be mindful of links/attachments.
>
> Hi,
>
> It largely looks OK to me, just a few small comments below.
>
> On 7/18/25 05:16, Anderson Choi wrote:
>> ARINC653 specificaion requires partition scheduling to be
>> deterministic
>
> Typo: s/specificaion/specification/
>
Addr
On 2025-07-22 14:07, Teddy Astie wrote:
do_sched_op(SCHEDOP_yield) just calls vcpu_yield(). Remove the indirection
through the hypercall handler and use the function directly.
Perform the same for SCHEDOP_block.
Not a functional change.
Signed-off-by: Teddy Astie
---
xen/arch/x86/hvm/hvm.c
From: Denis Mukhin
Introduce domain_console for grouping data structures used for integrating
domain's diagnostic console with Xen's console driver.
Group all pbuf-related data structures under domain_console. Rename the moved
fields to plain .buf, .idx and .lock names, since all uses of the fi
On Fri, 18 Jul 2025, Alejandro Vallejo wrote:
> Some arguments do want to be adjusted one way or the other spec_ctrl.c makes
> heavy assumptions about there not being any hwdom/ctldom separation, and both
> having domain_id == 0. There are other cases.
>
> Yet another option is to single-out the H
On Thu, Jul 17, 2025 at 12:59:15PM +0200, Alejandro Vallejo wrote:
> +Juergen for late-hwdom bit
>
> Hi,
>
> On Mon Jun 23, 2025 at 8:28 PM CEST, dmkhn wrote:
> > From: Denis Mukhin
> >
> > Remove the open-coded domain ID 0 and replace it with a call to
> > get_initial_domain_id().
>
> Ideally
On Tue, 22 Jul 2025, Jan Beulich wrote:
> On 22.07.2025 15:31, Alejandro Vallejo wrote:
> > On Tue Jul 22, 2025 at 2:57 PM CEST, Jan Beulich wrote:
> >> On 22.07.2025 14:37, Alejandro Vallejo wrote:
> >>> On Tue Jul 22, 2025 at 2:18 PM CEST, Jan Beulich wrote:
> On 22.07.2025 13:59, Alejandro
On Tue, 22 Jul 2025, Alejandro Vallejo wrote:
> It deals with a single domain, and will be called on a later patch
> by a new function parse_dom0less_node(), so the new name is apt.
>
> Also, pass parameters using boot_domain instead as the plan is to use it
> as dumping gound for all the extracte
On Tue, 22 Jul 2025, Alejandro Vallejo wrote:
> Let the function return an errno, so fallible bindings are not precluded.
>
> Signed-off-by: Alejandro Vallejo
Reviewed-by: Stefano Stabellini
On Tue, 22 Jul 2025, Alejandro Vallejo wrote:
> Later patches move the bindings to a separate function and expect the
> outputs to land in fields of a boot_domain. Adjust llc_color_str to
> live inside boot_domain so it can be parsed later on.
>
> Not a functional change.
>
> Signed-off-by: Aleja
On Tue, 22 Jul 2025, Alejandro Vallejo wrote:
> It's meant to be usable by anyone with CONFIG_DOM0LESS_BOOT.
>
> While moving, replace an inclusion of public/domctl.h by a forward
> declaration.
>
> Signed-off-by: Alejandro Vallejo
Acked-by: Stefano Stabellini
On Tue, Jun 24, 2025 at 08:07:55AM +0200, Jan Beulich wrote:
> On 23.06.2025 20:28, dm...@proton.me wrote:
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -492,7 +492,7 @@ static int late_hwdom_init(struct domain *d)
> > struct domain *dom0;
> > int rv;
> >
> > -if
On Tue, 22 Jul 2025, Alejandro Vallejo wrote:
> On Tue Jul 22, 2025 at 2:10 PM CEST, Jan Beulich wrote:
> > On 22.07.2025 13:59, Alejandro Vallejo wrote:
> >> From: Alejandro Vallejo
> >>
> >> When later on x86 starts using this file in later patches it won't find
> >> device_tree.h because it's
On Thu, Jul 17, 2025 at 12:34:56PM +0200, Alejandro Vallejo wrote:
> On Mon Jun 23, 2025 at 8:28 PM CEST, dmkhn wrote:
> > From: Denis Mukhin
> >
> > Use %pd for domain identification in error/panic messages in create_dom0().
> >
> > No functional change.
> >
> > Signed-off-by: Denis Mukhin
>
>
On Thu, Jul 17, 2025 at 12:27:48PM +0200, Alejandro Vallejo wrote:
> Hi,
>
> Sorry I'm so late to this. I have a few suggestions to improve the ergonomics
> of domid handling in dom0less/Hyperlaunch.
Thanks for the feedback!
>
> On Mon Jun 23, 2025 at 8:28 PM CEST, dmkhn wrote:
> > From: Denis
From: Stefano Stabellini
In preparation of exposing vITS to domUs, generalize arm_iommu_map_page
and arm_iommu_unmap_page to allow ITS doorbell mappings with dfn != mfn.
The mfn does not need to be passed to guest_physmap_remove_page since
there is no mfn checking on the p2m_iommu_map_{rw,ro} p2
From: Stefano Stabellini
Up until f9f6b22abf1d "xen/arm: Map ITS doorbell register to IOMMU page
tables" the only caller of iommu_map on ARM was grant_table.c which has
a specific usage model and restrictions as described by the in-code
comment in arm_iommu_map_page.
f9f6b22abf1d introduced a se
Hi,
It largely looks OK to me, just a few small comments below.
On 7/18/25 05:16, Anderson Choi wrote:
> ARINC653 specificaion requires partition scheduling to be deterministic
Typo: s/specificaion/specification/
> and periodic over time.
>
> However, the use of current timestamp (now) as the
do_sched_op(SCHEDOP_yield) just calls vcpu_yield(). Remove the indirection
through the hypercall handler and use the function directly.
Perform the same for SCHEDOP_block.
Not a functional change.
Signed-off-by: Teddy Astie
---
xen/arch/x86/hvm/hvm.c | 3 ++-
xen/arch/x86/hvm/svm
On Tue Jul 22, 2025 at 4:45 PM CEST, Jan Beulich wrote:
> On 17.07.2025 19:51, Alejandro Vallejo wrote:
>> Make alloc_dom0_vcpu0() viable as a general vcpu0 allocator. Keep
>> behaviour on any hwdom/ctldom identical to that dom0 used to have, and
>> make non-dom0 have auto node affinity.
>>
>> Ren
On July 22, 2025 12:57:33 AM PDT, Greg KH wrote:
>On Tue, Jul 22, 2025 at 03:22:18PM +0800, WangYuli wrote:
>> Hi greg k-h,
>>
>> On 2025/7/16 16:08, Greg KH wrote:
>> > > Signed-off-by: WangYuli
>> > Is your name all one word like that, or should there be a " " between
>> > them?
>>
>> If I we
On 2025-07-22 03:46, Michal Orzel wrote:
Trying to boot a compressed kernel with UBSAN enabled, results in the
following warning:
(XEN) UBSAN: Undefined behaviour in common/device-tree/kernel.c:21:12
(XEN) load of misaligned address 0a0040f89867 for type 'uint32_t'
(XEN) which requires 4 byte
On 7/22/25 4:35 PM, Jan Beulich wrote:
On 22.07.2025 16:25, Oleksii Kurochko wrote:
On 7/22/25 2:00 PM, Jan Beulich wrote:
On 22.07.2025 13:34, Oleksii Kurochko wrote:
On 7/22/25 12:41 PM, Oleksii Kurochko wrote:
On 7/21/25 2:18 PM, Jan Beulich wrote:
On 18.07.2025 11:52, Oleksii Kurochko w
On 22.07.2025 16:57, Oleksii Kurochko wrote:
>
> On 7/21/25 3:34 PM, Jan Beulich wrote:
>> On 17.07.2025 18:37, Oleksii Kurochko wrote:
>>> On 7/2/25 11:25 AM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
> Add support for down large memory mappings ("superpages") in th
On 22.07.2025 17:02, Roger Pau Monné wrote:
> On Wed, Jul 16, 2025 at 06:31:03PM +0200, Jan Beulich wrote:
>> On 16.07.2025 18:00, Roger Pau Monne wrote:
>>> In a livepatch payload relocations will refer to included functions. If
>>> that function happens to be a replacement for an existing Xen fu
On 16.07.2025 22:15, Petr Beneš wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -2686,8 +2686,8 @@ static int cf_check hvmemul_tlb_op(
> return rc;
> }
>
> -static int cf_check hvmemul_vmfunc(
> -struct x86_emulate_ctxt *ctxt)
> +#ifdef CONFIG_ALTP2M
>
On Mon, Jul 21, 2025 at 04:51:33PM +0100, Ross Lagerwall wrote:
> On Wed, Jul 16, 2025 at 5:00 PM Roger Pau Monne wrote:
> >
> > In a livepatch payload relocations will refer to included functions. If
> > that function happens to be a replacement for an existing Xen function, the
> > relocations
Hi Jan,
On 22/07/2025 15:21, Jan Beulich wrote:
> On 22.07.2025 13:41, Oleksii Moisieiev wrote:
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -1096,6 +1096,15 @@ affinities to prefer but be not limited to the
>> specified node(s).
>>
>> Pin dom0
On Wed, Jul 16, 2025 at 06:31:03PM +0200, Jan Beulich wrote:
> On 16.07.2025 18:00, Roger Pau Monne wrote:
> > In a livepatch payload relocations will refer to included functions. If
> > that function happens to be a replacement for an existing Xen function, the
> > relocations on the livepatch pa
On 7/21/25 3:34 PM, Jan Beulich wrote:
On 17.07.2025 18:37, Oleksii Kurochko wrote:
On 7/2/25 11:25 AM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
Add support for down large memory mappings ("superpages") in the RISC-V
p2m mapping so that smaller, more precise mappings ("
On 16.07.2025 22:15, Petr Beneš wrote:
> From: Petr Beneš
>
> The p2m_altp2m_check() stub was previously declared on all architectures,
> even though the altp2m feature is only supported on x86. This patch removes
> the unused stub definitions from ARM, PPC, and RISC-V, and wraps the actual
> usa
On 16.07.2025 22:15, Petr Beneš wrote:
> From: Petr Beneš
>
> Wrap the p2m_is_altp2m() check with IS_ENABLED(CONFIG_ALTP2M) to allow the
> compiler to short-circuit the condition at build time when ALTP2M is disabled.
>
> Signed-off-by: Petr Beneš
Reviewed-by: Jan Beulich
On 17.07.2025 19:51, Alejandro Vallejo wrote:
> Make alloc_dom0_vcpu0() viable as a general vcpu0 allocator. Keep
> behaviour on any hwdom/ctldom identical to that dom0 used to have, and
> make non-dom0 have auto node affinity.
>
> Rename the function to alloc_dom_vcpu0() to reflect this change in
Ping for additional reviews. Especially patches 3, 4, and 5, which cover
a wide range of drivers..
Am 13.06.25 um 11:00 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
On 22.07.2025 16:25, Oleksii Kurochko wrote:
> On 7/22/25 2:00 PM, Jan Beulich wrote:
>> On 22.07.2025 13:34, Oleksii Kurochko wrote:
>>> On 7/22/25 12:41 PM, Oleksii Kurochko wrote:
On 7/21/25 2:18 PM, Jan Beulich wrote:
> On 18.07.2025 11:52, Oleksii Kurochko wrote:
>> On 7/17/25 12:
Ping for additional reviews. Especially patches 3, 4, and 5, which cover
a wide range of drivers..
Am 13.06.25 um 11:00 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
On 7/22/25 2:00 PM, Jan Beulich wrote:
On 22.07.2025 13:34, Oleksii Kurochko wrote:
On 7/22/25 12:41 PM, Oleksii Kurochko wrote:
On 7/21/25 2:18 PM, Jan Beulich wrote:
On 18.07.2025 11:52, Oleksii Kurochko wrote:
On 7/17/25 12:25 PM, Jan Beulich wrote:
On 17.07.2025 10:56, Oleksii Kurochko
Xen currently uses an ASID scheme where:
- ASIDs are cycled where a "TLB flush" is performed
- When ASIDs wrap around, perform a full TLB flush
- In exceptional cases, stop using ASIDs
However, the TLB control mode used only flushes the current active ASID of
the logical processor. Which mean that
Add a guest config parameter "xenstore_feature_mask" allowing to limit
the Xenstore features the guest can see and use. This can be needed in
order to allow migrating a guest to a host running a Xenstore version
providing less features than the source host.
Signed-off-by: Juergen Gross
---
docs/
Add the Xenstore feature value to the output of "xl info" in order to
prepare for a future capability to limit Xenstore features visible by
a guest.
Signed-off-by: Juergen Gross
---
tools/xl/Makefile | 3 ++-
tools/xl/xl_info.c | 22 ++
2 files changed, 24 insertions(+), 1
Add per domain server features, which are initialized by the supported
features at domain introduction, or by live update from the migration
stream. This requires to add the DOMAIN_DATA record to the migration
stream, but for now it will only contain the feature word.
Advertise the Xenstore featur
Add support for XS_SET_FEATURE and XS_GET_FEATURE to xenstored.
Signed-off-by: Juergen Gross
---
tools/xenstored/core.c | 4 +++
tools/xenstored/domain.c | 60
tools/xenstored/domain.h | 8 ++
3 files changed, 72 insertions(+)
diff --git a/tools/
In order to prepare xenstored supporting migration stream versions
other than 1, add a parameter to the live update command allowing to
specify the version of the migration stream.
This will allow going back from xenstored using version 2 per default
to a xenstored only accepting version 1.
For n
Add functions for getting and setting Xenstore features to libxenstore:
xs_get_features_supported(): return the features supported by the
running Xenstore implementation as defined in xs_wire.h via the
XENSTORE_SERVER_FEATURE_* macros.
xs_get_features_domain(): return the features offered for a s
Add all the missing migration record structures and defines to the
xenstore_state.h header file.
Update the version of the migration stream to "2". In order to allow
receiving version 1 streams, change the version check of the header
to reject only streams with a version higher than the current kn
Add support for limiting the optional Xenstore features via domain
configuration. This will be needed when adding features like limiting
the scope of Xenstore watch events.
This patch series is handling only the xl/libxl side, libxenstore and
C Xenstore (xenstored and xenstore-stubdom). Oxenstored
On 22.07.25 11:23, Jan Beulich wrote:
On 18.07.2025 12:11, Grygorii Strashko wrote:
From: Grygorii Strashko
On platforms without PIRQ support evtchn_move_pirqs()/send_guest_pirq()
functions are unreachable (Misra rule 2.1).
Move these function under CONFIG_HAS_PIRQ ifdefs to fix Misra rule
On 7/21/25 3:42 PM, Jan Beulich wrote:
On 18.07.2025 16:49, Oleksii Kurochko wrote:
On 7/2/25 12:09 PM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
Implement the mfn_valid() macro to verify whether a given MFN is valid by
checking that it falls within the range [start_page
On 22.07.2025 15:31, Alejandro Vallejo wrote:
> On Tue Jul 22, 2025 at 2:57 PM CEST, Jan Beulich wrote:
>> On 22.07.2025 14:37, Alejandro Vallejo wrote:
>>> On Tue Jul 22, 2025 at 2:18 PM CEST, Jan Beulich wrote:
On 22.07.2025 13:59, Alejandro Vallejo wrote:
> Reduce the scope of every var
On Tue Jul 22, 2025 at 2:57 PM CEST, Jan Beulich wrote:
> On 22.07.2025 14:37, Alejandro Vallejo wrote:
>> On Tue Jul 22, 2025 at 2:18 PM CEST, Jan Beulich wrote:
>>> On 22.07.2025 13:59, Alejandro Vallejo wrote:
Reduce the scope of every variable so they are reinitialised. "iommu",
for i
On 22.07.2025 14:37, Alejandro Vallejo wrote:
> On Tue Jul 22, 2025 at 2:18 PM CEST, Jan Beulich wrote:
>> On 22.07.2025 13:59, Alejandro Vallejo wrote:
>>> Reduce the scope of every variable so they are reinitialised. "iommu",
>>> for instance, isn't being cleared, so the wrong flags may make it t
On 22.07.2025 13:41, Oleksii Moisieiev wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1105,6 +1105,15 @@ which serves as Driver domain. The SCMI will be
> disabled for Dom0/hwdom and
> SCMI nodes removed from Dom0/hwdom device tree.
> (for exampl
On 22.07.2025 13:41, Oleksii Moisieiev wrote:
> This commit introduces two helper functions, `__memcpy_fromio` and
> `__memcpy_toio`, to provide a robust mechanism for copying data between
> standard memory and memory-mapped I/O (MMIO) space for the ARM
> architecture.
>
> These functions are desi
On Tue Jul 22, 2025 at 2:10 PM CEST, Jan Beulich wrote:
> On 22.07.2025 13:59, Alejandro Vallejo wrote:
>> From: Alejandro Vallejo
>>
>> When later on x86 starts using this file in later patches it won't find
>> device_tree.h because it's only transitively included by arm.
>>
>> Make it explicit
On Tue Jul 22, 2025 at 2:18 PM CEST, Jan Beulich wrote:
> On 22.07.2025 13:59, Alejandro Vallejo wrote:
>> Reduce the scope of every variable so they are reinitialised. "iommu",
>> for instance, isn't being cleared, so the wrong flags may make it to
>> domains that should not have them.
>
> Yet "fo
On 22.07.2025 13:41, Oleksii Moisieiev wrote:
> @@ -859,7 +860,25 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
> case XEN_DOMCTL_test_assign_device:
> case XEN_DOMCTL_deassign_device:
> case XEN_DOMCTL_get_device_group:
> +int ret1;
> +
>
On 22.07.2025 13:41, Oleksii Moisieiev wrote:
> Change -ENOPNOTSUPP error code to -ENXIO when iommu is disabled during
> iommu_do_domctl call. As was discussed in [1]
>
> [0]:
> https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2506171701190.1780597@ubuntu-linux-20-04-desktop/
Hmm, I can't r
On 22.07.2025 13:41, Oleksii Moisieiev wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1096,6 +1096,15 @@ affinities to prefer but be not limited to the
> specified node(s).
>
> Pin dom0 vcpus to their respective pcpus
>
> +### scmi_smc_passthr
On 22.07.2025 13:59, Alejandro Vallejo wrote:
> Reduce the scope of every variable so they are reinitialised. "iommu",
> for instance, isn't being cleared, so the wrong flags may make it to
> domains that should not have them.
Yet "for instance" isn't quite right, is it? "iommu" is the only one wh
On 22.07.2025 13:59, Alejandro Vallejo wrote:
> From: Alejandro Vallejo
>
> When later on x86 starts using this file in later patches it won't find
> device_tree.h because it's only transitively included by arm.
>
> Make it explicit.
>
> Not a functional change.
>
> Signed-off-by: Alejandro Va
On 22.07.2025 14:03, Oleksii Kurochko wrote:
> On 7/21/25 3:39 PM, Jan Beulich wrote:
>> On 18.07.2025 16:37, Oleksii Kurochko wrote:
>>> On 7/2/25 12:28 PM, Jan Beulich wrote:
On 02.07.2025 12:09, Jan Beulich wrote:
> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>> @@ -613,3 +612,91 @
On 7/21/25 3:39 PM, Jan Beulich wrote:
On 18.07.2025 16:37, Oleksii Kurochko wrote:
On 7/2/25 12:28 PM, Jan Beulich wrote:
On 02.07.2025 12:09, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
@@ -613,3 +612,91 @@ void __iomem *ioremap(paddr_t pa, size_t len)
{
retur
Let the function return an errno, so fallible bindings are not precluded.
Signed-off-by: Alejandro Vallejo
---
xen/arch/arm/dom0less-build.c | 6 --
xen/common/device-tree/dom0less-build.c | 3 ++-
xen/include/xen/dom0less-build.h| 6 +++---
3 files changed, 9 insertions(+)
The builder in common code already does this, but it's not callable
independently from a separate location. Create a function x86 can
call to use its own domain builder, using createdomain arguments
as the parsed data.
The bindings are moved on the next patch so it's strict code motion.
Signed-of
Add the arguments that create_domain() takes to boot_domain. This creates
a consistent place to drop the outputs of the dom0less bindings.
Not a functional change. Later patches use these fields as the outputs of
the dom0less parsing functions.
Signed-off-by: Alejandro Vallejo
Acked-by: Stefano
It's meant to be usable by anyone with CONFIG_DOM0LESS_BOOT.
While moving, replace an inclusion of public/domctl.h by a forward
declaration.
Signed-off-by: Alejandro Vallejo
---
xen/arch/arm/dom0less-build.c | 2 +-
xen/arch/arm/domain_build.c | 2 +-
x
In later patches boot_domain becomes the common ground for the bindings
to drop the extracted information. In preparation for the bindings
themselves to be in a separate function, introduce kernel_info early in
the domain construction loop.
This simplifies a later diff, turning it into a strict cu
On 22.07.2025 13:34, Oleksii Kurochko wrote:
>
> On 7/22/25 12:41 PM, Oleksii Kurochko wrote:
>>
>>
>> On 7/21/25 2:18 PM, Jan Beulich wrote:
>>> On 18.07.2025 11:52, Oleksii Kurochko wrote:
On 7/17/25 12:25 PM, Jan Beulich wrote:
> On 17.07.2025 10:56, Oleksii Kurochko wrote:
>> On 7
Hi,
pipeline:
https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/1941315850
With boot_domain common between architectures, we're now in a position to use
it as the common ground to dump results of dom0less bindings. This series is
largely code motion with a few tweaks to make it sim
Reduce the scope of every variable so they are reinitialised. "iommu",
for instance, isn't being cleared, so the wrong flags may make it to
domains that should not have them.
Fixes: 1d2b4f3049fd("xen/arm, doc: Add a DT property to specify...")
Signed-off-by: Alejandro Vallejo
---
This is implicit
It deals with a single domain, and will be called on a later patch
by a new function parse_dom0less_node(), so the new name is apt.
Also, pass parameters using boot_domain instead as the plan is to use it
as dumping gound for all the extracted information from the bindings.
Not a functional chang
Later patches move the bindings to a separate function and expect the
outputs to land in fields of a boot_domain. Adjust llc_color_str to
live inside boot_domain so it can be parsed later on.
Not a functional change.
Signed-off-by: Alejandro Vallejo
---
xen/common/device-tree/dom0less-build.c |
From: Alejandro Vallejo
When later on x86 starts using this file in later patches it won't find
device_tree.h because it's only transitively included by arm.
Make it explicit.
Not a functional change.
Signed-off-by: Alejandro Vallejo
Acked-by: Stefano Stabellini
Reviewed-by: Jason Andryuk
-
In preparation for it to be usable on x86 with IBT, tag targets of
function pointers with cf_check
Signed-off-by: Alejandro Vallejo
Acked-by: Stefano Stabellini
Reviewed-by: Jason Andryuk
Reviewed-by: Edgar E. Iglesias
---
xen/common/device-tree/device-tree.c | 28 ++--
On 22.07.2025 12:41, Oleksii Kurochko wrote:
> On 7/21/25 2:18 PM, Jan Beulich wrote:
>> On 18.07.2025 11:52, Oleksii Kurochko wrote:
>>> On 7/17/25 12:25 PM, Jan Beulich wrote:
On 17.07.2025 10:56, Oleksii Kurochko wrote:
> On 7/16/25 6:18 PM, Jan Beulich wrote:
>> On 16.07.2025 18:07
According to the "7.1 Return Codes" section of DEN0028 [1]
INVALID_PARAMETER code (-3) is returned when one of the call
parameters has a non-supported value.
Adding this error code to the common smccc header file.
[1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6
Signed-o
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
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 interfac
This commit introduces two helper functions, `__memcpy_fromio` and
`__memcpy_toio`, to provide a robust mechanism for copying data between
standard memory and memory-mapped I/O (MMIO) space for the ARM
architecture.
These functions are designed to handle memory transfers safely,
accounting for pot
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
(su
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 |
+---
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
---
Changes in v5:
- rename dom0_scmi_smc_passthrough in documentation
.../arm/firmware/arm-scmi.rst
Change -ENOPNOTSUPP error code to -ENXIO when iommu is disabled during
iommu_do_domctl call. As was discussed in [1]
[0]:
https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2506171701190.1780597@ubuntu-linux-20-04-desktop/
Signed-off-by: Oleksii Moisieiev
---
Changes in v5:
- set error code
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 drive
1 - 100 of 127 matches
Mail list logo
