Re: [PATCH v3 13/16] x86/hyperlaunch: specify dom0 mode with device tree

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

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