|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v9 1/5] xen/domctl: chain SCI handling before IOMMU in assign_device domctl
On Fri, 29 Jan 2026, Jan Beulich wrote:
> On 30.01.2026 00:14, Stefano Stabellini wrote:
> > On Thu, 29 Jan 2026, Oleksii Moisieiev wrote:
> >> --- a/xen/arch/arm/firmware/sci.c
> >> +++ b/xen/arch/arm/firmware/sci.c
> >> @@ -126,6 +126,42 @@ 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;
> >
> > Should this be -ENXIO?
>
> Not unless further changes are made. That error code being set ...
>
> >> + switch ( domctl->cmd )
> >> + {
> >> + case XEN_DOMCTL_assign_device:
> >> + ret = -ENXIO;
>
> ... here makes sure that other XEN_DOMCTL_* making it into this function
> will ...
>
> >> + 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);
> >> +
> >> + break;
> >> +
> >> + default:
> >> + /* do not fail here as call is chained with iommu handling */
> >> + break;
>
> ... succeed (by making it here). If you used -ENXIO as initializer, ret would
> then need setting to 0 here. Which is functionally identical to what is there
> now.
OK you are right
> >> @@ -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;
> >
> > This should be -ENXIO?
>
> Why? Then several other XEN_DOMCTL_* would break. Or wait, no, nothing would
> break at all, as this stub looks to never come into play. It hence should be
> dropped.
Yes, good point, it can be dropped
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |