On 6/13/25 18: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. 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. 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.
I think the benefits of this are much reduced as long as the hardware domain is not strongly isolated from the other domains, in the sense that the hardware domain being able to compromise other domains is not considered a security vulnerability. Specifically, in safety-critical scenarios the hardware domain (which, to the best of my understanding, generally runs Linux) must not be able to compromise any of the safety- critical domains. This is, of course, achievable, but my understanding is that it isn't something guaranteed by upstream Xen. Rather, each user must ensure it by assigning any hardware that could compromise Xen to the control domain or a quarantine domain. Could this be included in documentation? -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
