On 4/16/25 09:38, Jan Beulich wrote:
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.
Yes and?
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.
OpenXT has done this for since it was XenClientXT, and those are driver
domains. We do distinguish between the two because a device model domain
is specific to provide the larger core device plane to a domain. While a
driver domain is a much narrower scope of providing a specific emulated
hardware device to one or more domains. As a result, they have totally
different security policies applied to them.
v/r,
dps
