On 16.04.2025 15:32, Daniel P. Smith wrote:
> On 4/10/25 07:57, Jan Beulich wrote:
>> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>>> --- a/xen/arch/x86/domain-builder/fdt.c
>>> +++ b/xen/arch/x86/domain-builder/fdt.c
>>> @@ -193,6 +193,25 @@ static int __init process_domain_node(
>>> bd->domid = (domid_t)val;
>>> printk(" domid: %d\n", bd->domid);
>>> }
>>> + else if ( strncmp(prop_name, "mode", name_len) == 0 )
>>> + {
>>> + if ( fdt_prop_as_u32(prop, &bd->mode) != 0 )
>>> + {
>>> + printk(" failed processing mode for domain %s\n", 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");
>>> + }
>>
>> My prior questions here remain: What's the significance of
>> BUILD_MODE_ENABLE_DM when set alongside BUILD_MODE_PARAVIRT? What about
>> any of the other bits being set?
>
> From boot-domain.h:
> /* On | Off */
> #define BUILD_MODE_PARAVIRT (1 << 0) /* PV | PVH/HVM */
> #define BUILD_MODE_ENABLE_DM (1 << 1) /* HVM | PVH */
>
> The logic says, if BUILD_MODE_PARAVIRT bit is not set, thus an HVM
> domain, check if BUILD_MODE_ENABLE_DM has been set. This is determin if
> the domain is what the toolstack differentiates as either an HVM or PVH
> domain. As you should know, there is no case of a PV domain requiring a
> backing device mode (DM) domain. IOW, BUILD_MODE_ENABLE_DM is only
> relevant to an HVM domain.
And hence should (my conclusion) never be set for a PV one.
Except - how wide or narrow do you mean "DM"? There are certainly cases
where a PV guest requires a qemu to serve as backend for one or more
devices. That's not what "DM" originally meant, but it goes in that
direction. Hence just to avoid such an ambiguity I think it's better to
properly reject any flags / flag combinations that we can't make sense
of.
Jan
