On 11.12.2024 18:48, Daniel P. Smith wrote:
> On 12/2/24 07:06, Jan Beulich wrote:
>> On 23.11.2024 19:20, Daniel P. Smith wrote:
>>> --- a/xen/arch/x86/domain_builder/fdt.c
>>> +++ b/xen/arch/x86/domain_builder/fdt.c
>>> @@ -141,6 +141,25 @@ static int __init process_domain_node(
>>> bd->domid = (domid_t)val;
>>> printk(" domid: %d\n", bd->domid);
>>> }
>>> + if ( match_fdt_property(fdt, prop, "mode" ) )
>>> + {
>>> + if ( fdt_prop_as_u32(prop, &bd->mode) != 0 )
>>> + {
>>> + printk(" failed processing mode for domain %s\n",
>>> + name == NULL ? "unknown" : name);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + printk(" mode: ");
>>> + if ( !(bd->mode & BUILD_MODE_PARAVIRT) ) {
>>> + if ( bd->mode & BUILD_MODE_ENABLE_DM )
>>> + printk("HVM\n");
>>> + else
>>> + printk("PVH\n");
>>> + }
>>> + else
>>> + printk("PV\n");
>>
>> Oh, and: What about BUILD_MODE_ENABLE_DM also being set here?
>
> Are you asking in the sense that the PV domain is being flag as a device
> model domain? Maybe I am missing something, but I am not aware of
> anything specific that must be set for a PV domain to operate as device
> model domain. If flask is in play, then there is a secure label
> requirement but that is separate of a mode that the domain must be
> running in. Please enlighten me if I am over looking something.
Rephrasing my question: Is it legitimate for BUILD_MODE_PARAVIRT to be
accompanied with BUILD_MODE_ENABLE_DM. If it is, what is the difference
between BUILD_MODE_PARAVIRT|BUILD_MODE_ENABLE_DM and plain
BUILD_MODE_PARAVIRT? If there's none, perhaps better to reject the flag
(retaining possible use for some future purpose)?
Jan
