Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document
On Thu, Mar 25, 2021 at 9:55 AM Stefano Stabellini wrote: > On Thu, 25 Mar 2021, Roger Pau Monné wrote: > > On Thu, Mar 25, 2021 at 10:14:31AM +0100, George Dunlap wrote: > > > > > > > On Mar 25, 2021, at 8:32 AM, Roger Pau Monne > > > > wrote: > > > > 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é > > > >> 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é > > > 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. > > > > > > My understanding was that one of the primary advantages of domB was > > > that you could compile and run arbitrary code in whatever language > > > you wanted to, using already known tools. If *all* we want to do is > > > to assign some pre-defined specific BDFs to specific domains, then > > > sure, we could add that capability to Xen. > > > > Well, it's not so easy because we require QEMU or pciback ATM on x86 > > in order to do pci passthrough to guests, so assigning BDFs to > > specific domains from the hypervisor would need to be done using vPCI > > (which is not yet ready for unprivileged guest usage) and only support > > HVM kind of guests strictly. > > > > Doing passthrough to PV guests directly from the hypervisor is > > impossible AFAICT without putting pciback inside of the hypervisor. > > > > > But suppose you wanted > > > to have the flexibility to handle changes in hardware at boot time? > > > “Scan through the PCI bus and assign anything that looks like a > > > network card to domNet, and anything that looks like a USB > > > controller to domUSB” is something you could easily do in domB, but > > > would be way too complicated to add to Xen. > > > > Right, but then you might as well create the domain from domB instead > > of doing it in the hypervisor? > > > > I'm not arguing about not using domB, I just don't see the benefit of > > creating a paused domain from the hypervisor that then requires the > > intervention of a further domain (domB) in order to finish creation. > > Won't it be simpler to just create the domain and attach the pci > > devices from domB? > > I think that the ability of creating multiple VMs from Xen is actually a > very good one to have for a few reasons. It would align x86 with ARM, it > would be useful in cases where PCI passthrough is not involved, and it > is a powerful tool to have in our toolbox. > > I see that handling PCI passthrough at domain creation time can be > difficult, so I think Christopher's solution is a good compromise. > > FYI for dom0less/ARM we have been discussing doing device assignment at > creation time, but the idea was to provide the PCI topology in device > tree to Xen to help with discovery. a quick note: - thanks for all the feedback and questions in this thread, which we will cover in the next version of the design document - we have made available the code developed for our prototype, first development milestone: https://github.com/apertussolutions/xen-hyperlaunch/tree/hyperlaunch-prototype-lcm - we look forward to discussion on the Community Call tomorrow Christopher
Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document
On Thu, 25 Mar 2021, Roger Pau Monné wrote: > On Thu, Mar 25, 2021 at 10:14:31AM +0100, George Dunlap wrote: > > > > > > > On Mar 25, 2021, at 8:32 AM, Roger Pau Monne wrote: > > > > > > 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é > > >> 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é > > 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. > > > > My understanding was that one of the primary advantages of domB was > > that you could compile and run arbitrary code in whatever language > > you wanted to, using already known tools. If *all* we want to do is > > to assign some pre-defined specific BDFs to specific domains, then > > sure, we could add that capability to Xen. > > Well, it's not so easy because we require QEMU or pciback ATM on x86 > in order to do pci passthrough to guests, so assigning BDFs to > specific domains from the hypervisor would need to be done using vPCI > (which is not yet ready for unprivileged guest usage) and only support > HVM kind of guests strictly. > > Doing passthrough to PV guests directly from the hypervisor is > impossible AFAICT without putting pciback inside of the hypervisor. > > > But suppose you wanted > > to have the flexibility to handle changes in hardware at boot time? > > “Scan through the PCI bus and assign anything that looks like a > > network card to domNet, and anything that looks like a USB > > controller to domUSB” is something you could easily do in domB, but > > would be way too complicated to add to Xen. > > Right, but then you might as well create the domain from domB instead > of doing it in the hypervisor? > > I'm not arguing about not using domB, I just don't see the benefit of > creating a paused domain from the hypervisor that then requires the > intervention of a further domain (domB) in order to finish creation. > Won't it be simpler to just create the domain and attach the pci > devices from domB? I think that the ability of creating multiple VMs from Xen is actually a very good one to have for a few reasons. It would align x86 with ARM, it would be useful in cases where PCI passthrough is not involved, and it is a powerful tool to have in our toolbox. I see that handling PCI passthrough at domain creation time can be difficult, so I think Christopher's solution is a good compromise. FYI for dom0less/ARM we have been discussing doing device assignment at creation time, but the idea was to provide the PCI topology in device tree to Xen to help with discovery.
Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document
On Thu, Mar 25, 2021 at 10:14:31AM +0100, George Dunlap wrote: > > > > On Mar 25, 2021, at 8:32 AM, Roger Pau Monne wrote: > > > > 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é > >> 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é > 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. > > My understanding was that one of the primary advantages of domB was > that you could compile and run arbitrary code in whatever language > you wanted to, using already known tools. If *all* we want to do is > to assign some pre-defined specific BDFs to specific domains, then > sure, we could add that capability to Xen. Well, it's not so easy because we require QEMU or pciback ATM on x86 in order to do pci passthrough to guests, so assigning BDFs to specific domains from the hypervisor would need to be done using vPCI (which is not yet ready for unprivileged guest usage) and only support HVM kind of guests strictly. Doing passthrough to PV guests directly from the hypervisor is impossible AFAICT without putting pciback inside of the hypervisor. > But suppose you wanted > to have the flexibility to handle changes in hardware at boot time? > “Scan through the PCI bus and assign anything that looks like a > network card to domNet, and anything that looks like a USB > controller to domUSB” is something you could easily do in domB, but > would be way too complicated to add to Xen. Right, but then you might as well create the domain from domB instead of doing it in the hypervisor? I'm not arguing about not using domB, I just don't see the benefit of creating a paused domain from the hypervisor that then requires the intervention of a further domain (domB) in order to finish creation. Won't it be simpler to just create the domain and attach the pci devices from domB? Thanks, Roger.
Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document
> On Mar 25, 2021, at 8:32 AM, Roger Pau Monne wrote: > > 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é 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é 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. My understanding was that one of the primary advantages of domB was that you could compile and run arbitrary code in whatever language you wanted to, using already known tools. If *all* we want to do is to assign some pre-defined specific BDFs to specific domains, then sure, we could add that capability to Xen. But suppose you wanted to have the flexibility to handle changes in hardware at boot time? “Scan through the PCI bus and assign anything that looks like a network card to domNet, and anything that looks like a USB controller to domUSB” is something you could easily do in domB, but would be way too complicated to add to Xen. -George
Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document
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é 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é > > > 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.
Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document
On 24.03.2021 20:10, Stefano Stabellini wrote: > On Wed, 24 Mar 2021, Christopher Clark wrote: > I'm also not sure how you are going to handle things like SR-IOV > devices. Right now SR-IOV capability is setup and initialized by the > hardware domain, and the new virtual devices are notified to Xen once > setup is done. Do you plan to move those bits into Xen, so that it can > setup and initialize the SR-IOV capability? While you could do it with the vPCI, as you point out this will not work for SR-IOV. With hyperlaunch, these cases will require the use of a boot domain, which is for all intents and purposes, a lightweight/restricted toolstack domain. The boot domain will have to do the necessary operations to ensure that when startup is finished, PCI passthrough will be successfully setup. Note, this may have to include the boot domain unpausing the hardware domain to help complete the setup before the boot domain can exit and allow the remaining domains to come online. >>> >>> OK, I was expecting hyperlaunch to do all domain creation in the >>> hypervisor. >> >> That is my expectation too. It is what we've been planning for in our >> work so far but we can work on explaining the steps involved in >> constructing the domains more clearly. >> >>> 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? > > Let's leave SR-IOV aside for a moment that can be a bit strange (if I > recall correctly sometimes VFs can only appear after the PF driver has > been loaded). Yes, and iirc beyond that the number of VFs can (in Linux at least) also be controlled (read: changed) when the driver is already loaded, via sysfs. I think such flexibility is desirable, as a device's resources may get partitioned differently depending on the number of VFs, and hence the number of VFs may affect individual VFs' (and maybe also the PF's) performance. Otoh if the system as a whole gets statically partitioned, one-time setup of VFs will of course do. I don't think though that SR-IOV can be left aside - whatever is to be done here needs to take it into consideration from the very beginning. Jan
Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document
On Wed, 24 Mar 2021, Christopher Clark wrote: > > > > I'm also not sure how you are going to handle things like SR-IOV > > > > devices. Right now SR-IOV capability is setup and initialized by the > > > > hardware domain, and the new virtual devices are notified to Xen once > > > > setup is done. Do you plan to move those bits into Xen, so that it can > > > > setup and initialize the SR-IOV capability? > > > > > > While you could do it with the vPCI, as you point out this will not work > > > for SR-IOV. With hyperlaunch, these cases will require the use of a boot > > > domain, which is for all intents and purposes, a lightweight/restricted > > > toolstack domain. > > > > > > The boot domain will have to do the necessary operations to ensure that > > > when startup is finished, PCI passthrough will be successfully setup. > > > Note, this may have to include the boot domain unpausing the hardware > > > domain to help complete the setup before the boot domain can exit and > > > allow the remaining domains to come online. > > > > OK, I was expecting hyperlaunch to do all domain creation in the > > hypervisor. > > That is my expectation too. It is what we've been planning for in our > work so far but we can work on explaining the steps involved in > constructing the domains more clearly. > > > 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? Let's leave SR-IOV aside for a moment that can be a bit strange (if I recall correctly sometimes VFs can only appear after the PF driver has been loaded). Just for my understanding, for regular PCI passthrough, why is it important that the device assignment is done later by the control domain, instead of straight away at domain creation by Xen? I am fine either way but I meant to ask if it is just to make the implementation easier or if there is some kind of policy involved.
Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document
> On Mar 24, 2021, at 12:53 PM, Christopher Clark > wrote: > > 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? AIUI, libxl actually does the latter: That is, PCI devices are added to the domain after the domain and qemu have been set up, but before they have been unpaused. One advantage of this is that it’s the same codepath for adding PCI devices at domain creation as for hotplug. -George
Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document
On Wed, Mar 24, 2021 at 1:01 AM Roger Pau Monné 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é > > wrote: > > > > > > Just took a quick look at it. > > > > > > On Mon, Mar 15, 2021 at 11:18:13PM -0400, Daniel P. Smith wrote: > > > > + > > > > +---+---++---+-+-+ > > > > + | **Xen Dom0** | **Linux** | **Late** | **Jail** | **Xen** | > > > > **Xen Hyperlaunch** | > > > > + | **(Classic)** | **KVM** | **HW Dom** | **house** | > > > > **dom0less**+-+---+ > > > > + | | || | | > > > > Static | Dynamic | > > > > + > > > > +===+===++===+=+=+===+ > > > > + | Hypervisor able to launch multiple VMs during host boot > > > >| > > > > + > > > > +---+---++---+-+-+---+ > > > > + | | || Y | Y | > > > > Y| Y | > > > > + > > > > +---+---++---+-+-+---+ > > > > + | Hypervisor supports Static Partitioning > > > >| > > > > + > > > > +---+---++---+-+-+---+ > > > > + | | || Y | Y | > > > > Y| | > > > > + > > > > +---+---++---+-+-+---+ > > > > + | Able to launch VMs dynamically after host boot > > > >| > > > > + > > > > +---+---++---+-+-+---+ > > > > + | Y | Y | Y*| Y | Y*| > > > >| Y | > > > > + > > > > +---+---++---+-+-+---+ > > > > + | Supports strong isolation between all VMs started at host boot > > > >| > > > > + > > > > +---+---++---+-+-+---+ > > > > + | | || Y | Y | > > > > Y| Y | > > > > + > > > > +---+---++---+-+-+---+ > > > > + | Enables flexible sequencing of VM start during host boot > > > >| > > > > + > > > > +---+---++---+-+-+---+ > > > > + | | || | | > > > > Y| Y | > > > > + > > > > +---+---++---+-+-+---+ > > > > + | Prevent all-powerful static root domain being launched at boot > > > >| > > > > + > > > > +---+---++---+-+-+---+ > > > > + | | || | Y*| > > > > Y| Y | > > > > + > > > > +---+---++---+-+-+---+ > > > > + | Operates without a Highly-privileged management VM (eg. Dom0) > > > >| > > > > + > > > > +---+---++---+-+-+---+ > > > > + | | | Y*| | Y*| > > > > Y| Y | > > > > + > > > > +---+---++---+-+-+---+ > > > > + | Operates without a privileged toolstack VM (Control Domain) > > > >| > > > > + > > > > +---+---++---+-+-+---+ > > > > + | | || | Y*| > > > > Y| | > > > > + > > > > +---+---++---+-+-+---+ > > > > + | Extensible VM configuration applied before launch of VMs at host > > > > boot | > > > > + > > > > +---+---++---+-+-+---+ > > > > + | | || | | > > > > Y| Y | > > > > + > > > > +---+---++---+-+-+---+ > > > > + | Flexible granular assignment of permissions and functions to VMs > > > >| > > > > + > > > >
Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document
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é wrote: > > > > Just took a quick look at it. > > > > On Mon, Mar 15, 2021 at 11:18:13PM -0400, Daniel P. Smith wrote: > > > + > > > +---+---++---+-+-+ > > > + | **Xen Dom0** | **Linux** | **Late** | **Jail** | **Xen** | > > > **Xen Hyperlaunch** | > > > + | **(Classic)** | **KVM** | **HW Dom** | **house** | > > > **dom0less**+-+---+ > > > + | | || | | > > > Static | Dynamic | > > > + > > > +===+===++===+=+=+===+ > > > + | Hypervisor able to launch multiple VMs during host boot > > > | > > > + > > > +---+---++---+-+-+---+ > > > + | | || Y | Y | > > > Y| Y | > > > + > > > +---+---++---+-+-+---+ > > > + | Hypervisor supports Static Partitioning > > > | > > > + > > > +---+---++---+-+-+---+ > > > + | | || Y | Y | > > > Y| | > > > + > > > +---+---++---+-+-+---+ > > > + | Able to launch VMs dynamically after host boot > > > | > > > + > > > +---+---++---+-+-+---+ > > > + | Y | Y | Y*| Y | Y*| > > > | Y | > > > + > > > +---+---++---+-+-+---+ > > > + | Supports strong isolation between all VMs started at host boot > > > | > > > + > > > +---+---++---+-+-+---+ > > > + | | || Y | Y | > > > Y| Y | > > > + > > > +---+---++---+-+-+---+ > > > + | Enables flexible sequencing of VM start during host boot > > > | > > > + > > > +---+---++---+-+-+---+ > > > + | | || | | > > > Y| Y | > > > + > > > +---+---++---+-+-+---+ > > > + | Prevent all-powerful static root domain being launched at boot > > > | > > > + > > > +---+---++---+-+-+---+ > > > + | | || | Y*| > > > Y| Y | > > > + > > > +---+---++---+-+-+---+ > > > + | Operates without a Highly-privileged management VM (eg. Dom0) > > > | > > > + > > > +---+---++---+-+-+---+ > > > + | | | Y*| | Y*| > > > Y| Y | > > > + > > > +---+---++---+-+-+---+ > > > + | Operates without a privileged toolstack VM (Control Domain) > > > | > > > + > > > +---+---++---+-+-+---+ > > > + | | || | Y*| > > > Y| | > > > + > > > +---+---++---+-+-+---+ > > > + | Extensible VM configuration applied before launch of VMs at host boot > > > | > > > + > > > +---+---++---+-+-+---+ > > > + | | || | | > > > Y| Y | > > > + > > > +---+---++---+-+-+---+ > > > + | Flexible granular assignment of permissions and functions to VMs > > > | > > > + > > > +---+---++---+-+-+---+ > > > + | | || | | > > > Y| Y | > > > + > > >
Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document
On Thu, Mar 18, 2021 at 9:43 AM Roger Pau Monné wrote: > > Just took a quick look at it. > > On Mon, Mar 15, 2021 at 11:18:13PM -0400, Daniel P. Smith wrote: > > + > > +---+---++---+-+-+ > > + | **Xen Dom0** | **Linux** | **Late** | **Jail** | **Xen** | > > **Xen Hyperlaunch** | > > + | **(Classic)** | **KVM** | **HW Dom** | **house** | > > **dom0less**+-+---+ > > + | | || | | > > Static | Dynamic | > > + > > +===+===++===+=+=+===+ > > + | Hypervisor able to launch multiple VMs during host boot > >| > > + > > +---+---++---+-+-+---+ > > + | | || Y | Y |Y > >| Y | > > + > > +---+---++---+-+-+---+ > > + | Hypervisor supports Static Partitioning > >| > > + > > +---+---++---+-+-+---+ > > + | | || Y | Y |Y > >| | > > + > > +---+---++---+-+-+---+ > > + | Able to launch VMs dynamically after host boot > >| > > + > > +---+---++---+-+-+---+ > > + | Y | Y | Y*| Y | Y*| > >| Y | > > + > > +---+---++---+-+-+---+ > > + | Supports strong isolation between all VMs started at host boot > >| > > + > > +---+---++---+-+-+---+ > > + | | || Y | Y |Y > >| Y | > > + > > +---+---++---+-+-+---+ > > + | Enables flexible sequencing of VM start during host boot > >| > > + > > +---+---++---+-+-+---+ > > + | | || | |Y > >| Y | > > + > > +---+---++---+-+-+---+ > > + | Prevent all-powerful static root domain being launched at boot > >| > > + > > +---+---++---+-+-+---+ > > + | | || | Y*|Y > >| Y | > > + > > +---+---++---+-+-+---+ > > + | Operates without a Highly-privileged management VM (eg. Dom0) > >| > > + > > +---+---++---+-+-+---+ > > + | | | Y*| | Y*|Y > >| Y | > > + > > +---+---++---+-+-+---+ > > + | Operates without a privileged toolstack VM (Control Domain) > >| > > + > > +---+---++---+-+-+---+ > > + | | || | Y*|Y > >| | > > + > > +---+---++---+-+-+---+ > > + | Extensible VM configuration applied before launch of VMs at host boot > >| > > + > > +---+---++---+-+-+---+ > > + | | || | |Y > >| Y | > > + > > +---+---++---+-+-+---+ > > + | Flexible granular assignment of permissions and functions to VMs > >| > > + > > +---+---++---+-+-+---+ > > + | | || | |Y > >| Y | > > + > > +---+---++---+-+-+---+ > > + | Supports extensible VM measurement architecture for DRTM and > > attestation | > > + > > +---+---++---+-+-+---+ > > + | | |
Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document
Just took a quick look at it. On Mon, Mar 15, 2021 at 11:18:13PM -0400, Daniel P. Smith wrote: > + > +---+---++---+-+-+ > + | **Xen Dom0** | **Linux** | **Late** | **Jail** | **Xen** | **Xen > Hyperlaunch** | > + | **(Classic)** | **KVM** | **HW Dom** | **house** | > **dom0less**+-+---+ > + | | || | | Static > | Dynamic | > + > +===+===++===+=+=+===+ > + | Hypervisor able to launch multiple VMs during host boot > | > + > +---+---++---+-+-+---+ > + | | || Y | Y |Y > | Y | > + > +---+---++---+-+-+---+ > + | Hypervisor supports Static Partitioning > | > + > +---+---++---+-+-+---+ > + | | || Y | Y |Y > | | > + > +---+---++---+-+-+---+ > + | Able to launch VMs dynamically after host boot > | > + > +---+---++---+-+-+---+ > + | Y | Y | Y*| Y | Y*| > | Y | > + > +---+---++---+-+-+---+ > + | Supports strong isolation between all VMs started at host boot > | > + > +---+---++---+-+-+---+ > + | | || Y | Y |Y > | Y | > + > +---+---++---+-+-+---+ > + | Enables flexible sequencing of VM start during host boot > | > + > +---+---++---+-+-+---+ > + | | || | |Y > | Y | > + > +---+---++---+-+-+---+ > + | Prevent all-powerful static root domain being launched at boot > | > + > +---+---++---+-+-+---+ > + | | || | Y*|Y > | Y | > + > +---+---++---+-+-+---+ > + | Operates without a Highly-privileged management VM (eg. Dom0) > | > + > +---+---++---+-+-+---+ > + | | | Y*| | Y*|Y > | Y | > + > +---+---++---+-+-+---+ > + | Operates without a privileged toolstack VM (Control Domain) > | > + > +---+---++---+-+-+---+ > + | | || | Y*|Y > | | > + > +---+---++---+-+-+---+ > + | Extensible VM configuration applied before launch of VMs at host boot > | > + > +---+---++---+-+-+---+ > + | | || | |Y > | Y | > + > +---+---++---+-+-+---+ > + | Flexible granular assignment of permissions and functions to VMs > | > + > +---+---++---+-+-+---+ > + | | || | |Y > | Y | > + > +---+---++---+-+-+---+ > + | Supports extensible VM measurement architecture for DRTM and attestation > | > + > +---+---++---+-+-+---+ > + | | || | |Y > | Y | > + > +---+---++---+-+-+---+ > + | PCI passthrough configured at host boot > | >
