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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.