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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.