On 26.09.2025 06:41, Penny, Zheng wrote: >> -----Original Message----- >> From: Jan Beulich <[email protected]> >> Sent: Thursday, September 25, 2025 10:29 PM >> >> On 25.09.2025 11:41, Penny, Zheng wrote: >>>> -----Original Message----- >>>> From: Jan Beulich <[email protected]> >>>> Sent: Thursday, September 11, 2025 9:30 PM >>>> >>>> On 10.09.2025 09:38, Penny Zheng wrote: >>>>> --- a/xen/include/xsm/xsm.h >>>>> +++ b/xen/include/xsm/xsm.h >>>>> @@ -55,8 +55,8 @@ struct xsm_ops { >>>>> void (*security_domaininfo)(struct domain *d, >>>>> struct xen_domctl_getdomaininfo *info); >>>>> int (*domain_create)(struct domain *d, uint32_t ssidref); >>>>> - int (*getdomaininfo)(struct domain *d); >>>>> #ifdef CONFIG_MGMT_HYPERCALLS >>>>> + int (*getdomaininfo)(struct domain *d); >>>>> int (*domctl_scheduler_op)(struct domain *d, int op); >>>>> int (*sysctl_scheduler_op)(int op); >>>>> int (*set_target)(struct domain *d, struct domain *e); @@ >>>>> -234,7 >>>>> +234,11 @@ static inline int xsm_domain_create( >>>>> >>>>> static inline int xsm_getdomaininfo(xsm_default_t def, struct >>>>> domain >>>>> *d) { >>>>> +#ifdef CONFIG_MGMT_HYPERCALLS >>>>> return alternative_call(xsm_ops.getdomaininfo, d); >>>>> +#else >>>>> + return -EOPNOTSUPP; >>>>> +#endif >>>>> } >>>> >>>> This is in use by a Xenstore sysctl and a Xenstore domctl. The sysctl >>>> is hence already broken with the earlier series. Now the domctl is >>>> also being screwed up. I don't think MGMT_HYPERCALLS really ought to >>>> extend to any operations available to other than the core toolstack. >>>> That's the Xenstore ones here, but also the ones used by qemu (whether run >>>> in >> Dom0 or a stubdom). >>> >>> Maybe not only limited to the core toolstack. In dom0less/hyperlaunched >> scenarios, hypercalls are strictly limited. QEMU is also limited to pvh >> machine type >> and with very restricted functionality(, only acting as a few virtio-pci >> devices >> backend). @Andryuk, Jason @Stabellini, Stefano Am I understanding correctly >> and >> thoroughly about our scenario here for upstream? >>> Tracking the codes, if Xenstore is created as a stub domain, it requires >> getdomaininfo-domctl to acquire related info. Sorry, I haven't found how it >> was >> called in QEMU... >> >> It's not "it"; it's different ones. First and foremost I was thinking of >> * XEN_DOMCTL_ioport_mapping >> * XEN_DOMCTL_memory_mapping >> * XEN_DOMCTL_bind_pt_irq >> * XEN_DOMCTL_unbind_pt_irq >> but there may be others (albeit per the dummy xsm_domctl() this is the full >> set). As >> a general criteria, anything using XSM_DM_PRIV checking can in principle be >> called by qemu. >> > > Understood. > I assume that they are all for device passthrough. We are not accepting > device passthrough via core toolstack in dom0less/hyperlaunch-ed scenarios. > Jason has developed device passthrough through device tree to only accept > "static configured" passthrough in dom0less/hyperlaunch-ed scenario, while it > is still internal , it may be the only accept way to do device passthrough in > dom0less/hyperlaunch-ed scenario.
Right, but no matter what your goals, the upstream contributions need to be self- consistent. I.e. not (risk to) break other functionality. (Really the four domctl-s mentioned above might better have been put elsewhere, e.g. as dm-ops. Moving them may be an option here.) Jan
