Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Mar 24, 2021 at 05:53:26AM -0700, Christopher Clark wrote:
> On Wed, Mar 24, 2021 at 1:01 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> >
> > On Tue, Mar 23, 2021 at 10:39:53AM -0700, Christopher Clark wrote:
> > > On Thu, Mar 18, 2021 at 9:43 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> 
> > > wrote:
> > If you offload domain creation of guests with
> > pci-passthrough devices to a control domain and/or hardware domain,
> > I'm not sure I see the difference from normal domain creation, ie:
> > it's no longer something specific to hyperlaunch, as I could achieve
> > the same by using the existing xendomains init script.
> 
> So that's not what we've proposed, and hopefully not what we'll need to do.
> 
> Do you know if there is a need to perform work to support the
> assignment of PCI devices at the point of domain creation (ie. in
> domain_create), rather than handling it in a later step of domain
> configuration, prior to the domain being started?

So while I think you could indeed create a domain from the hypervisor
in a paused state and attach the pci devices later from a
control/hardware domain, I don't see much benefit in doing it. If you
need to end up waiting for a control/hardware domain to attach the
devices and unpause you might as well do the whole domain creation
from such control/hardware domain.

Is this split done because the control/hardware domain would have a
very strict set of permissions only allowing attachment of pci
devices but not domain creation?

I think the permissions required by a control/hardware domain to
attach a pci device to another guests would end up being fairly
similar to the ones required to just create a domain from scratch,
because a pci attachment requires modifications to the p2m.

Thanks, Roger.