On 14.06.2025 00:47, Stefano Stabellini wrote: > On Wed, 11 Jun 2025, Jan Beulich wrote: >> On 11.06.2025 00:57, Jason Andryuk wrote: >>> To add more flexibility in system configuration add the new >>> DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model. >>> >>> Thie new flag corresponds to allowing XSM_DM_PRIV for the domain. This >>> will enable running device model emulators (QEMU) from the assigne >>> domain for multiple target domains. >>> >>> Stubdoms assign target allowing the stubdom to serve as the device >>> model for a single domain. This new flag allows the single domain to >>> provide emulators for multiple guests. >>> >>> The specific scenario is a disaggregated system with the hardware domain >>> providing device models for muitple guest domains. >> >> Why the hardware domain? Unless a DM also needs access to some of the >> physical hardware, it ought to run in a separate domain. Conceivably >> such a domain could service multiply guests, so maybe the "single >> target" concept presently used for stubdom simply needed extending? > > Not necessarily. While it is possible to have driver domains, it is not > the default configuration. > > In a default configuration, the hardware domain gets all the hardware by > default and therefore will also run the PV backends and Virtio backends. > The Virtio backends require DM hypercalls. Let me elaborate further. > > In the datacenter, we have Dom0 typically with all the hardware, the > backends (PV and Virtio), and also the toolstack. Then all other domains > are created dynamically by the toolstack. Driver domains are possible > but not very common. > > In automotive/embedded, the total number of domains is static, so we can > create them using dom0less. We don't need the toolstack to create VMs. > Also, we have safety concerns, so we want to take away as much > privileges as possible from Dom0.
At least purely by the wording, this ... > This is easy because thanks to > dom0less, we don't need the toolstack and we don't need to create VMs > dynamically. > > So the model is that Dom0 becomes the hardware domain: it has all the > drivers and backends but it is not privileged in the sense of > creating/destroying other VMs. If a user wants to have Dom0 "super > powers", they can create an optional Control Domain. The Control Domain > is expected to be tiny, such as XTF or Zephyr. It will have the ability > that Dom0 used to have but without the drivers. From a privilege > perspective, the Control Domain could create additional VMs, but in > automotive/embedded it is not expected to be a use-case because the > total number of VMs is still static. > > So your point about driver domains. Yes, one can have driver domains the > same way that one can have driver domains in the datacenter but it is > not the default. ... kind of contradicts this: Running e.g. qemu in Dom0 gives Dom0 quite a bit of extra privilege. (And no, the term "driver domain" does not describe a domain running DMs, imo.) Jan > The new default for embedded is what I described above > and I think it is a very widely applicable concept across industries: > automotive, industrial, robotics, etc. and also across vendors: AMD, > Xilinx, Renesas, EPAM, ARM, etc.
