On 11.06.2025 00:57, Jason Andryuk wrote: > Theses are the broad changes needed for a split hardware / control > domain. > > An earlier posting gave device_model privileges to hardware domain. For > this posting, it was split out into a new capability. This way the > operator can choose where to run the device models without making the > hardware domain have the permissions. > > The first patch add XSM_HW_PRIV for the hardware hypercalls. Unlike the > first posting, the control domain can call these hypercalls even though > it doesn't really make sense. The idea was to keep the control domain > all powerful from an XSM perspective. > > SILO is changed to allow control, hardwware or xenstore to service > domUs. Xenstore and hardware will use grants for PV interfaces. > Control wouldn't typically provide PV interfaces to domUs, but it is > given the permision to do so. Again, to keep control all powerful. > > xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo this is not strictly > needed. xenconsoled could read Xen's dmesg. If it's in hwdom, then > that permission would be required. SYSCTL_physinfo is mainly to silence > xl messages, which are mostly cosmetic. > > Jason Andryuk (4): > xen/xsm: Add XSM_HW_PRIV > xsm/silo: Support hwdom/control domains > xen: Add DOMAIN_CAPS_DEVICE_MODEL & XEN_DOMCTL_CDF_device_model > xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
Overall I can't help the impression that this level of disaggregation simply requires the use of Flask. Jan
