[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC 00/15] dom0less step1: boot multiple domains from device tree



On Wed, Jun 13, 2018 at 03:15:09PM -0700, Stefano Stabellini wrote:
> Hi all,
> 
> This is first step toward "dom0less" as discussed in the various
> certifications related threads and discussions.
> 
> The goal of this series is to enable Xen to boot multiple domains in
> parallel, in addition to dom0, out of information found on device tree.
> 
> The device tree based boot protocol is extended to carry information
> about DomUs. Based on that information, Xen creates and starts one or
> more DomUs. DomUs created this way don't have access to xenstore, as
> xenstore is not started yet. This is actually OK, because this is meant
> for mission critical applications that typically only access directly
> assigned devices. They cannot tolerate interference or increased IRQ
> latency due to PV protocols. Device assignment is not actually covered
> by this series, it will be added later.
> 
> DomUs can print to the Xen serial using the CONSOLEIO hypercalls. A
> virtual PL011 is also emulated for them so that they can use their
> regular PL011 driver. This allows unmodified guests to run as Xen on ARM
> guests -- no Xen support needed at all. Console input also comes from
> the Xen serial: the Ctrl-AAA switching mechanism is extended to switch
> among domUs, dom0, and Xen.

Hi Stefano,

I think this looks very promising!

A question, do you have any thoughts on how we in the long run could
try to keep xl configs somewhat on par with the format here?

Or would the device-tree naming of options eventually have to diverge.

Eventually we'll need support for describing arbitrary memory maps and
device passthrough via device-tree for these domUs.

Thanks & Best regards,
Edgar


> 
> Cheers,
> 
> Stefano
> 
> 
> Stefano Stabellini (15):
>       xen: allow console_io hypercalls from DomUs on ARM
>       xen/arm: move a few guest related #defines to public/arch-arm.h
>       xen/arm: extend device tree based multiboot protocol
>       xen/arm: do not pass dt_host to make_memory_node and 
> make_hypervisor_node
>       xen/arm: rename acpi_make_chosen_node to make_chosen_node
>       xen/arm: add BOOTMOD_DOMU_KERNEL/RAMDISK
>       xen/arm: increase MAX_MODULES
>       xen/arm: probe domU kernels and initrds
>       xen/arm: refactor construct_dom0
>       xen/arm: introduce construct_domU
>       xen/arm: generate a simple device tree for domUs
>       xen/arm: generate vpl011 node on device tree for domU
>       xen/arm: Allow vpl011 to be used by DomU
>       xen/arm: call construct_domU from start_xen and start DomU VMs
>       xen: support console_switching between Dom0 and DomUs on ARM
> 
>  docs/misc/arm/device-tree/booting.txt | 102 +++++++
>  tools/libxl/libxl_arm.c               |  26 --
>  xen/arch/arm/bootfdt.c                |   4 +
>  xen/arch/arm/domain_build.c           | 533 
> +++++++++++++++++++++++++++-------
>  xen/arch/arm/kernel.c                 |  54 ++++
>  xen/arch/arm/kernel.h                 |   2 +
>  xen/arch/arm/setup.c                  |  52 +++-
>  xen/arch/arm/vpl011.c                 |  98 +++++--
>  xen/common/device_tree.c              |   6 +-
>  xen/drivers/char/console.c            |  51 +++-
>  xen/include/asm-arm/setup.h           |  10 +-
>  xen/include/asm-arm/vpl011.h          |   2 +
>  xen/include/asm-x86/setup.h           |   2 +
>  xen/include/public/arch-arm.h         |  26 ++
>  xen/include/xen/device_tree.h         |   2 +-
>  15 files changed, 789 insertions(+), 181 deletions(-)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.