[Public] > -----Original Message----- > From: Jan Beulich <[email protected]> > Sent: Thursday, September 25, 2025 10:29 PM > To: Penny, Zheng <[email protected]> > Cc: Huang, Ray <[email protected]>; Daniel P. Smith > <[email protected]>; [email protected]; Andryuk, Jason > <[email protected]>; Stabellini, Stefano <[email protected]> > Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() with > CONFIG_MGMT_HYPERCALLS > > On 25.09.2025 11:41, Penny, Zheng wrote: > > [Public] > > > >> -----Original Message----- > >> From: Jan Beulich <[email protected]> > >> Sent: Thursday, September 11, 2025 9:30 PM > >> To: Penny, Zheng <[email protected]> > >> Cc: Huang, Ray <[email protected]>; Daniel P. Smith > >> <[email protected]>; [email protected] > >> Subject: Re: [PATCH v2 18/26] xen/domctl: wrap xsm_getdomaininfo() > >> with CONFIG_MGMT_HYPERCALLS > >> > >> 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. The major role of QEMU in dom0less/hyperlaunch-ed scenario is to provide limited virtio-pci devices backend. So we need hypercalls majorly involving ioreq server, event channel, virtual interrupt injection and foreign memory mapping, which shall not use XSM_DM_PRIV(xsm_iomem_permission()/xsm_irq_permission()/xsm_iomem_mapping()) checking, I assume. > Jan
