Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL & XEN_DOMCTL_CDF_device_model

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 13 Jun 2025, Demi Marie Obenour wrote:
> 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?

Yes, I agree that it should be included in the documentation.