From: Jan Beulich <jbeulich@suse.com>
To: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>,
Grygorii Strashko <grygorii_strashko@epam.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Bertrand Marquis" <bertrand.marquis@arm.com>,
"Juergen Gross" <jgross@suse.com>,
"Julien Grall" <julien@xen.org>,
"Michal Orzel" <michal.orzel@amd.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu
Date: Mon, 19 May 2025 20:54:54 +0200 [thread overview]
Message-ID: <092559d7-ddfd-44f2-9854-779770e24b8a@suse.com> (raw)
In-Reply-To: <4f58bf9c47c40413ee9250c4cd21458382aac857.1747669845.git.oleksii_moisieiev@epam.com>
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
next prev parent reply other threads:[~2025-05-19 18:55 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-19 15:50 [RFC PATCH v4 0/8] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Oleksii Moisieiev
2025-05-19 15:50 ` [RFC PATCH v4 2/8] xen/arm: scmi-smc: update to be used under sci subsystem Oleksii Moisieiev
2025-05-19 23:29 ` Stefano Stabellini
2025-05-19 15:50 ` [RFC PATCH v4 1/8] xen/arm: add generic SCI subsystem Oleksii Moisieiev
2025-05-19 23:45 ` Stefano Stabellini
2025-05-19 15:50 ` [RFC PATCH v4 3/8] xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent Oleksii Moisieiev
2025-05-20 0:18 ` Stefano Stabellini
2025-05-19 15:50 ` [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu Oleksii Moisieiev
2025-05-19 18:54 ` Jan Beulich [this message]
2025-05-22 0:25 ` Stefano Stabellini
2025-05-22 6:18 ` Jan Beulich
2025-06-12 11:42 ` Oleksii Moisieiev
2025-06-12 13:10 ` Grygorii Strashko
2025-06-18 0:04 ` Stefano Stabellini
2025-06-19 16:15 ` Oleksii Moisieiev
2025-06-22 21:30 ` Stefano Stabellini
2025-06-24 8:42 ` Oleksii Moisieiev
2025-06-24 8:47 ` Jan Beulich
2025-06-24 8:48 ` Oleksii Moisieiev
2025-06-23 7:15 ` Jan Beulich
2025-06-23 7:28 ` Oleksii Moisieiev
2025-06-25 19:56 ` Oleksii Moisieiev
2025-06-26 6:10 ` Jan Beulich
2025-06-26 13:07 ` Oleksii Moisieiev
2025-06-26 14:41 ` Jan Beulich
2025-06-26 15:01 ` Oleksii Moisieiev
2025-05-19 15:50 ` [RFC PATCH v4 7/8] docs: arm: add SCI SCMI SMC multi-agent driver docs Oleksii Moisieiev
2025-05-19 15:50 ` [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver Oleksii Moisieiev
2025-05-23 20:06 ` Stefano Stabellini
2025-06-02 7:17 ` Bertrand Marquis
2025-06-12 12:03 ` Oleksii Moisieiev
2025-06-12 12:10 ` Grygorii Strashko
2025-06-17 23:38 ` Stefano Stabellini
2025-06-18 7:22 ` Julien Grall
2025-06-19 16:15 ` Oleksii Moisieiev
2025-06-22 21:50 ` Stefano Stabellini
2025-06-19 16:15 ` Oleksii Moisieiev
2025-06-05 22:44 ` Julien Grall
2025-06-12 12:03 ` Oleksii Moisieiev
2025-06-17 23:22 ` Stefano Stabellini
2025-06-17 23:56 ` Stefano Stabellini
2025-06-19 16:15 ` Oleksii Moisieiev
2025-06-22 22:15 ` Stefano Stabellini
2025-06-23 8:06 ` Julien Grall
2025-06-23 19:27 ` Stefano Stabellini
2025-06-23 20:38 ` Julien Grall
2025-06-23 20:42 ` Stefano Stabellini
2025-06-23 21:58 ` Julien Grall
2025-06-25 19:47 ` Oleksii Moisieiev
2025-06-18 7:28 ` Julien Grall
2025-06-19 16:15 ` Oleksii Moisieiev
2025-05-19 15:50 ` [RFC PATCH v4 4/8] docs: arm: add docs for SCMI over SMC calls forwarding driver Oleksii Moisieiev
2025-05-19 15:50 ` [RFC PATCH v4 8/8] docs: arm: proposal to add separate SCMI node for Xen agent Oleksii Moisieiev
2025-05-23 20:19 ` Stefano Stabellini
2025-06-12 12:03 ` Oleksii Moisieiev
2025-06-18 0:35 ` Stefano Stabellini
2025-06-19 16:15 ` [RFC PATCH v4 8/8] docs: armproposa: l " Oleksii Moisieiev
2025-06-22 21:57 ` Stefano Stabellini
2025-06-23 8:02 ` Julien Grall
2025-06-25 19:47 ` Oleksii Moisieiev
2025-06-25 20:32 ` Julien Grall
2025-06-29 15:41 ` Oleksii Moisieiev
2025-06-29 18:34 ` Julien Grall
2025-06-30 11:57 ` Oleksii Moisieiev
2025-06-30 12:13 ` Julien Grall
2025-06-30 22:33 ` Stefano Stabellini
2025-06-05 22:40 ` [RFC PATCH v4 0/8] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support Julien Grall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=092559d7-ddfd-44f2-9854-779770e24b8a@suse.com \
--to=jbeulich@suse.com \
--cc=Oleksii_Moisieiev@epam.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=bertrand.marquis@arm.com \
--cc=grygorii_strashko@epam.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.