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

[Jason Andryuk <jason.andryuk@amd.com>]

On 2025-06-11 09:24, 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?

One configuration is the hardware domain running QEMU for the 
virtio-gpu.  In an earlier iteration, I allowed XSM_DM_PRIV for 
is_hardware_domain().  Rightfully, there was some questioning of that 
hardcoding.  Adding a new flag allows it to be configurable.

Maybe target could be extended.  I was thinking that could be left for 
the stubdom case as it is today.  i.e. a 1-1 device model.  But a 1-N 
case could be handled this way.

Today dom0 XSM_DM_PRIV falls through to is_control_domain().  The idea 
was place a new check directly corresponding to XSM_DM_PRIV.

Regards,
Jason