All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Julien Grall <julien.grall@arm.com>
Cc: artem_mygaiev@epam.com, Stefano Stabellini <stefanos@xilinx.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	andrii_anisov@epam.com, xen-devel@lists.xen.org
Subject: Re: [PATCH RFC 10/15] xen/arm: introduce construct_domU
Date: Thu, 5 Jul 2018 16:00:32 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1807051358020.13502@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <cd863dbb-93c2-71b3-a96b-b427a1f259a5@arm.com>

On Thu, 14 Jun 2018, Julien Grall wrote:
> Hi,
> 
> On 13/06/18 23:15, Stefano Stabellini wrote:
> > Similar to construct_dom0, construct_domU creates a barebone DomU guest.
> > Default to 1 max vcpu and 64MB of memory if not specified otherwise.
> > 
> > The device tree node passed as argument is compatible "xen,domU", see
> > docs/misc/arm/device-tree/booting.txt.
> > 
> > Allocate all vcpus on cpu0 initially.
> 
> I don't think this comment is true. __construct_domain will allocate vCPUs in
> cycle.

I'll remove the comment


> > 
> > Signed-off-by: Stefano Stabellini <stefanos@xilinx.com>
> > ---
> >   xen/arch/arm/domain_build.c | 37 +++++++++++++++++++++++++++++++++++++
> >   xen/include/asm-arm/setup.h |  2 ++
> >   2 files changed, 39 insertions(+)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index b31c563..02a7f94 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2187,6 +2187,43 @@ int __init __construct_domain(struct domain *d,
> > struct kernel_info *kinfo)
> >       return 0;
> >   }
> >   +int __init construct_domU(struct domain *d, struct dt_device_node *node)
> > +{
> > +    struct kernel_info kinfo = {};
> > +    int rc;
> > +    const char *cpus = NULL, *mem = NULL;
> > +
> > +    printk("*** LOADING DOMU ***\n");
> > +
> > +    d->max_vcpus = 1;
> > +    rc = dt_property_read_string(node, "cpus", &cpus);
> > +    if ( !rc )
> > +        d->max_vcpus = simple_strtoul(cpus, &cpus, 0);
> > +
> > +    kinfo.unassigned_mem = MB(64);
> > +    rc = dt_property_read_string(node, "mem", &mem);
> > +    if ( !rc )
> > +        kinfo.unassigned_mem = parse_size_and_unit(mem, &mem);
> > +
> > +    d->vcpu = xzalloc_array(struct vcpu *, d->max_vcpus);
> > +    if ( !d->vcpu )
> > +        return -ENOMEM;;
> > +    if ( alloc_vcpu(d, 0, 0) == NULL )
> > +        return -ENOMEM;
> > +    d->max_pages = ~0U;
> > +
> > +    kinfo.d = d;
> > +
> > +    rc = kernel_probe_domU(&kinfo, node);
> > +    if ( rc < 0 )
> > +        return rc;
> > +
> > +    d->arch.type = kinfo.type;
> > +    allocate_memory(d, &kinfo);
> 
> allocate_memory() will allocate direct mapped memory but you impose a static
> memory layout for the guest. Both are not going to work very well together.
> 
> So you probably want to extend allocate_memory to support allocating memory
> for a given region.

Yes, I'll extend allocate_memory to respect the current domU memory layout.


> > +
> > +    return __construct_domain(d, &kinfo);
> > +}
> > +
> >   int __init construct_dom0(struct domain *d)
> >   {
> >       struct kernel_info kinfo = {};
> > diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> > index 903782f..e9f9905 100644
> > --- a/xen/include/asm-arm/setup.h
> > +++ b/xen/include/asm-arm/setup.h
> > @@ -2,6 +2,7 @@
> >   #define __ARM_SETUP_H_
> >     #include <public/version.h>
> > +#include <xen/device_tree.h>
> >     #define MIN_FDT_ALIGN 8
> >   #define MAX_FDT_SIZE SZ_2M
> > @@ -71,6 +72,7 @@ void acpi_create_efi_mmap_table(struct domain *d,
> >   int acpi_make_efi_nodes(void *fdt, struct membank tbl_add[]);
> >     int construct_dom0(struct domain *d);
> > +int construct_domU(struct domain *d, struct dt_device_node *node);
> >     void discard_initial_modules(void);
> >   void dt_unreserved_regions(paddr_t s, paddr_t e,

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

  reply	other threads:[~2018-07-05 23:00 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-13 22:15 [PATCH RFC 00/15] dom0less step1: boot multiple domains from device tree Stefano Stabellini
2018-06-13 22:15 ` [PATCH RFC 01/15] xen: allow console_io hypercalls from DomUs on ARM Stefano Stabellini
2018-06-14 15:33   ` Julien Grall
2018-06-13 22:15 ` [PATCH RFC 02/15] xen/arm: move a few guest related #defines to public/arch-arm.h Stefano Stabellini
2018-06-14 15:36   ` Julien Grall
2018-06-14 21:15     ` Stefano Stabellini
2018-06-15 16:21       ` Julien Grall
2018-07-02 20:37         ` Stefano Stabellini
2018-07-02 21:13           ` Julien Grall
2018-07-02 21:38             ` Stefano Stabellini
2018-07-03 10:22               ` Julien Grall
2018-07-03 21:30                 ` Stefano Stabellini
2018-07-04  7:20                   ` Julien Grall
2018-06-27 14:11   ` Wei Liu
2018-06-13 22:15 ` [PATCH RFC 03/15] xen/arm: extend device tree based multiboot protocol Stefano Stabellini
2018-06-14 16:07   ` Julien Grall
2018-07-02 21:31     ` Stefano Stabellini
2018-07-03  9:35       ` Edgar E. Iglesias
2018-07-03 22:23         ` Stefano Stabellini
2018-07-03 10:40       ` Julien Grall
2018-07-03 22:16         ` Stefano Stabellini
2018-07-04 16:27           ` Julien Grall
2018-06-13 22:15 ` [PATCH RFC 04/15] xen/arm: do not pass dt_host to make_memory_node and make_hypervisor_node Stefano Stabellini
2018-06-14 16:10   ` Julien Grall
2018-06-14 21:24     ` Stefano Stabellini
2018-06-13 22:15 ` [PATCH RFC 05/15] xen/arm: rename acpi_make_chosen_node to make_chosen_node Stefano Stabellini
2018-06-14 16:16   ` Julien Grall
2018-06-14 22:01     ` Stefano Stabellini
2018-06-13 22:15 ` [PATCH RFC 06/15] xen/arm: add BOOTMOD_DOMU_KERNEL/RAMDISK Stefano Stabellini
2018-06-13 22:15 ` [PATCH RFC 07/15] xen/arm: increase MAX_MODULES Stefano Stabellini
2018-07-06  2:10   ` Doug Goldstein
2018-07-06 10:17     ` Julien Grall
2018-06-13 22:15 ` [PATCH RFC 08/15] xen/arm: probe domU kernels and initrds Stefano Stabellini
2018-06-14 16:45   ` Julien Grall
2018-07-05 20:38     ` Stefano Stabellini
2018-06-13 22:15 ` [PATCH RFC 09/15] xen/arm: refactor construct_dom0 Stefano Stabellini
2018-06-14 17:16   ` Julien Grall
2018-06-14 23:35     ` Stefano Stabellini
2018-06-15 16:32       ` Julien Grall
2018-07-05 20:55         ` Stefano Stabellini
2018-07-05 21:06           ` Julien Grall
2018-07-06 23:11             ` Stefano Stabellini
2018-06-13 22:15 ` [PATCH RFC 10/15] xen/arm: introduce construct_domU Stefano Stabellini
2018-06-14 17:25   ` Julien Grall
2018-07-05 23:00     ` Stefano Stabellini [this message]
2018-06-13 22:15 ` [PATCH RFC 11/15] xen/arm: generate a simple device tree for domUs Stefano Stabellini
2018-06-14 18:13   ` Julien Grall
2018-07-05 23:59     ` Stefano Stabellini
2018-07-06 10:22       ` Julien Grall
2018-07-06 16:16         ` Stefano Stabellini
2018-06-13 22:15 ` [PATCH RFC 12/15] xen/arm: generate vpl011 node on device tree for domU Stefano Stabellini
2018-06-15 16:58   ` Julien Grall
2018-07-06 17:11     ` Stefano Stabellini
2018-06-13 22:15 ` [PATCH RFC 13/15] xen/arm: Allow vpl011 to be used by DomU Stefano Stabellini
2018-06-15 17:38   ` Julien Grall
2018-07-06 23:10     ` Stefano Stabellini
2018-06-13 22:15 ` [PATCH RFC 14/15] xen/arm: call construct_domU from start_xen and start DomU VMs Stefano Stabellini
2018-06-15 18:24   ` Julien Grall
2018-07-06 23:11     ` Stefano Stabellini
2018-07-09 12:48       ` Julien Grall
2018-07-09 20:59         ` Stefano Stabellini
2018-07-09 21:06           ` Julien Grall
2018-07-09 21:23             ` Stefano Stabellini
2018-06-13 22:15 ` [PATCH RFC 15/15] xen: support console_switching between Dom0 and DomUs on ARM Stefano Stabellini
2018-06-14 19:08 ` [PATCH RFC 00/15] dom0less step1: boot multiple domains from device tree Edgar E. Iglesias
2018-06-14 20:34   ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.10.1807051358020.13502@sstabellini-ThinkPad-X260 \
    --to=sstabellini@kernel.org \
    --cc=andrii_anisov@epam.com \
    --cc=artem_mygaiev@epam.com \
    --cc=julien.grall@arm.com \
    --cc=stefanos@xilinx.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.