Re: [Xen-devel] [PATCH RFC 14/15] xen/arm: call construct_domU from start_xen and start DomU VMs
On Mon, 9 Jul 2018, Julien Grall wrote: > Hi, > > On 09/07/2018 21:59, Stefano Stabellini wrote: > > On Mon, 9 Jul 2018, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 07/07/18 00:11, Stefano Stabellini wrote: > > > > On Fri, 15 Jun 2018, Julien Grall wrote: > > > > > On 06/13/2018 11:15 PM, Stefano Stabellini wrote: > > > > > > Introduce support for the "xen,domU" compatible node on device tree. > > > > > > Create new DomU VMs based on the information found on device tree > > > > > > under > > > > > > "xen,domU". > > > > > > > > > > While I like the idea of having multiple domain created by Xen, I > > > > > think > > > > > there > > > > > are still few open questions here: > > > > > 1) The domains will be listed via "xl list". So are they still > > > > > manageable via DOMCTL? > > > > > > > > Yes, they are. There is an argument for making them "hidden" from > > > > DOMCTLs, but that is not done as part of this series. Future work. > > > > > > What will happen with libxl today? Is the toolstack going to be confused? > > > > The toolstack can list the running domains without problems with `xl > > list' (although they have no name). Also, xl vcpu-pin works fine. > > However, some operations might not work correctly though. For instance, > > `xl destroy' cannot completely get rid of the domain. I'll add info > > about these limitations to a separate dom0less document (as you also > > suggested below), because it is not part of the multiboot spec. > > > > > > > > > > > > > > > > > 2) Is it possible to restart those domains? > > > > > > > > No they can't be restarted. For example, their original kernel is gone > > > > from memory. > > > > > > So what will happen if you use "xl restart" on them? > > > > Do you mean `xl reboot'? The command executes but nothing happens. > > > > > > > > > > > > > > > > > 3) If a domain crash, what will happen? Are they just going to > > > > > sit > > > > > there using resources until the platform rebooted? > > > > > > > > The entire platform needs to be rebooted. > > > > > > That should be clarified somewhere in the documentation. > > > > Yes, you are right. I'll add this to the new dom0less doc. > > > > > > > > > > > > > > > > > 4) How do you handle scheduling? Is it still possible to do it > > > > > via > > > > > Dom0? How about the dom0less situation? > > > > > > > > The scheduler can be chosen via the Xen command line option. It is also > > > > possible to do that from dom0 (if there is a dom0). > > > > > > Can you explain how the vCPUs are going to get pinned via the command > > > line? > > > > Today, only dom0 vCPUs can get automatically pinned with a Xen command > > line option. However, `xl vcpu-pin' in dom0 works with other domains > > started by Xen at boot, and the NULL scheduler doesn't require pinning. > > FYI for my own usage, I plan to use the NULL scheduler. > > Well your series is called "Dom0less", so using Dom0 to pin the vCPU does not > look right to me. > > But even with NULL scheduler you may want to pin a vCPU to a given pCPU. > Imagine a big.LITTLE environment. However, NULL scheduler is not supported, so > it feels a little odd that there are no way to configure guest DomU without > Dom0 in play. > > So there is some clarification needed here. I'll add a note about this limitation to the dom0less doc I am writing. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC 14/15] xen/arm: call construct_domU from start_xen and start DomU VMs
Hi, On 09/07/2018 21:59, Stefano Stabellini wrote: On Mon, 9 Jul 2018, Julien Grall wrote: Hi Stefano, On 07/07/18 00:11, Stefano Stabellini wrote: On Fri, 15 Jun 2018, Julien Grall wrote: On 06/13/2018 11:15 PM, Stefano Stabellini wrote: Introduce support for the "xen,domU" compatible node on device tree. Create new DomU VMs based on the information found on device tree under "xen,domU". While I like the idea of having multiple domain created by Xen, I think there are still few open questions here: 1) The domains will be listed via "xl list". So are they still manageable via DOMCTL? Yes, they are. There is an argument for making them "hidden" from DOMCTLs, but that is not done as part of this series. Future work. What will happen with libxl today? Is the toolstack going to be confused? The toolstack can list the running domains without problems with `xl list' (although they have no name). Also, xl vcpu-pin works fine. However, some operations might not work correctly though. For instance, `xl destroy' cannot completely get rid of the domain. I'll add info about these limitations to a separate dom0less document (as you also suggested below), because it is not part of the multiboot spec. 2) Is it possible to restart those domains? No they can't be restarted. For example, their original kernel is gone from memory. So what will happen if you use "xl restart" on them? Do you mean `xl reboot'? The command executes but nothing happens. 3) If a domain crash, what will happen? Are they just going to sit there using resources until the platform rebooted? The entire platform needs to be rebooted. That should be clarified somewhere in the documentation. Yes, you are right. I'll add this to the new dom0less doc. 4) How do you handle scheduling? Is it still possible to do it via Dom0? How about the dom0less situation? The scheduler can be chosen via the Xen command line option. It is also possible to do that from dom0 (if there is a dom0). Can you explain how the vCPUs are going to get pinned via the command line? Today, only dom0 vCPUs can get automatically pinned with a Xen command line option. However, `xl vcpu-pin' in dom0 works with other domains started by Xen at boot, and the NULL scheduler doesn't require pinning. FYI for my own usage, I plan to use the NULL scheduler. Well your series is called "Dom0less", so using Dom0 to pin the vCPU does not look right to me. But even with NULL scheduler you may want to pin a vCPU to a given pCPU. Imagine a big.LITTLE environment. However, NULL scheduler is not supported, so it feels a little odd that there are no way to configure guest DomU without Dom0 in play. So there is some clarification needed here. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC 14/15] xen/arm: call construct_domU from start_xen and start DomU VMs
On Mon, 9 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 07/07/18 00:11, Stefano Stabellini wrote:
> > On Fri, 15 Jun 2018, Julien Grall wrote:
> > > On 06/13/2018 11:15 PM, Stefano Stabellini wrote:
> > > > Introduce support for the "xen,domU" compatible node on device tree.
> > > > Create new DomU VMs based on the information found on device tree under
> > > > "xen,domU".
> > >
> > > While I like the idea of having multiple domain created by Xen, I think
> > > there
> > > are still few open questions here:
> > > 1) The domains will be listed via "xl list". So are they still
> > > manageable via DOMCTL?
> >
> > Yes, they are. There is an argument for making them "hidden" from
> > DOMCTLs, but that is not done as part of this series. Future work.
>
> What will happen with libxl today? Is the toolstack going to be confused?
The toolstack can list the running domains without problems with `xl
list' (although they have no name). Also, xl vcpu-pin works fine.
However, some operations might not work correctly though. For instance,
`xl destroy' cannot completely get rid of the domain. I'll add info
about these limitations to a separate dom0less document (as you also
suggested below), because it is not part of the multiboot spec.
> >
> >
> > > 2) Is it possible to restart those domains?
> >
> > No they can't be restarted. For example, their original kernel is gone
> > from memory.
>
> So what will happen if you use "xl restart" on them?
Do you mean `xl reboot'? The command executes but nothing happens.
> >
> >
> > > 3) If a domain crash, what will happen? Are they just going to sit
> > > there using resources until the platform rebooted?
> >
> > The entire platform needs to be rebooted.
>
> That should be clarified somewhere in the documentation.
Yes, you are right. I'll add this to the new dom0less doc.
> >
> >
> > > 4) How do you handle scheduling? Is it still possible to do it via
> > > Dom0? How about the dom0less situation?
> >
> > The scheduler can be chosen via the Xen command line option. It is also
> > possible to do that from dom0 (if there is a dom0).
>
> Can you explain how the vCPUs are going to get pinned via the command line?
Today, only dom0 vCPUs can get automatically pinned with a Xen command
line option. However, `xl vcpu-pin' in dom0 works with other domains
started by Xen at boot, and the NULL scheduler doesn't require pinning.
FYI for my own usage, I plan to use the NULL scheduler.
> >
> >
> > > >
> > > > Introduce a simple global variable named max_init_domid to keep track of
> > > > the initial allocated domids.
> > >
> > > What is the exact goal of this new variable?
> >
> > The goal of this variable is to know the number of domUs allocated at
> > boot time by Xen. Specifically, it is used by console.c to switch the
> > serial input to the right domU.
>
> I don't think this is necessary. I will reply on the second version.
OK
> >
> >
> > > >
> > > > Move the discard_initial_modules after DomUs have been built
> > > >
> > > > Signed-off-by: Stefano Stabellini
> > > > ---
> > > >xen/arch/arm/domain_build.c | 2 --
> > > >xen/arch/arm/setup.c| 35 ++-
> > > >xen/include/asm-arm/setup.h | 2 ++
> > > >xen/include/asm-x86/setup.h | 2 ++
> > >
> > > You need to CC x86 maintainers for this change.
> >
> > I'll add them
> >
> >
> > > >4 files changed, 38 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > > index 97f14ca..e2d370f 100644
> > > > --- a/xen/arch/arm/domain_build.c
> > > > +++ b/xen/arch/arm/domain_build.c
> > > > @@ -2545,8 +2545,6 @@ int __init construct_dom0(struct domain *d)
> > > >if ( rc < 0 )
> > > >return rc;
> > > >-discard_initial_modules();
> > > > -
> > >
> > > Please mention this move in the commit message.
> >
> > It is mentioned: "Move the discard_initial_modules after DomUs have been
> > built"
>
> I missed that sorry.
>
> >
> >
> > > >return __construct_domain(d, );
> > > >}
> > > >diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > > > index 98bdb24..3723704 100644
> > > > --- a/xen/arch/arm/setup.c
> > > > +++ b/xen/arch/arm/setup.c
> > > > @@ -63,6 +63,8 @@ static unsigned long opt_xenheap_megabytes __initdata;
> > > >integer_param("xenheap_megabytes", opt_xenheap_megabytes);
> > > >#endif
> > > >+domid_t __read_mostly max_init_domid = 0;
> > > > +
> > > >static __used void init_done(void)
> > > >{
> > > >free_init_memory();
> > > > @@ -711,6 +713,8 @@ void __init start_xen(unsigned long
> > > > boot_phys_offset,
> > > >struct bootmodule *xen_bootmodule;
> > > >struct domain *dom0;
> > > >struct xen_domctl_createdomain dom0_cfg = {};
> > > > +struct dt_device_node *chosen;
> > > > +struct dt_device_node *node;
> > > > dcache_line_bytes =
Re: [Xen-devel] [PATCH RFC 14/15] xen/arm: call construct_domU from start_xen and start DomU VMs
Hi Stefano,
On 07/07/18 00:11, Stefano Stabellini wrote:
On Fri, 15 Jun 2018, Julien Grall wrote:
On 06/13/2018 11:15 PM, Stefano Stabellini wrote:
Introduce support for the "xen,domU" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domU".
While I like the idea of having multiple domain created by Xen, I think there
are still few open questions here:
1) The domains will be listed via "xl list". So are they still
manageable via DOMCTL?
Yes, they are. There is an argument for making them "hidden" from
DOMCTLs, but that is not done as part of this series. Future work.
What will happen with libxl today? Is the toolstack going to be confused?
2) Is it possible to restart those domains?
No they can't be restarted. For example, their original kernel is gone
from memory.
So what will happen if you use "xl restart" on them?
3) If a domain crash, what will happen? Are they just going to sit
there using resources until the platform rebooted?
The entire platform needs to be rebooted.
That should be clarified somewhere in the documentation.
4) How do you handle scheduling? Is it still possible to do it via
Dom0? How about the dom0less situation?
The scheduler can be chosen via the Xen command line option. It is also
possible to do that from dom0 (if there is a dom0).
Can you explain how the vCPUs are going to get pinned via the command line?
Introduce a simple global variable named max_init_domid to keep track of
the initial allocated domids.
What is the exact goal of this new variable?
The goal of this variable is to know the number of domUs allocated at
boot time by Xen. Specifically, it is used by console.c to switch the
serial input to the right domU.
I don't think this is necessary. I will reply on the second version.
Move the discard_initial_modules after DomUs have been built
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 2 --
xen/arch/arm/setup.c| 35 ++-
xen/include/asm-arm/setup.h | 2 ++
xen/include/asm-x86/setup.h | 2 ++
You need to CC x86 maintainers for this change.
I'll add them
4 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 97f14ca..e2d370f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2545,8 +2545,6 @@ int __init construct_dom0(struct domain *d)
if ( rc < 0 )
return rc;
-discard_initial_modules();
-
Please mention this move in the commit message.
It is mentioned: "Move the discard_initial_modules after DomUs have been
built"
I missed that sorry.
return __construct_domain(d, );
}
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 98bdb24..3723704 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -63,6 +63,8 @@ static unsigned long opt_xenheap_megabytes __initdata;
integer_param("xenheap_megabytes", opt_xenheap_megabytes);
#endif
+domid_t __read_mostly max_init_domid = 0;
+
static __used void init_done(void)
{
free_init_memory();
@@ -711,6 +713,8 @@ void __init start_xen(unsigned long boot_phys_offset,
struct bootmodule *xen_bootmodule;
struct domain *dom0;
struct xen_domctl_createdomain dom0_cfg = {};
+struct dt_device_node *chosen;
+struct dt_device_node *node;
dcache_line_bytes = read_dcache_line_bytes();
@@ -860,7 +864,7 @@ void __init start_xen(unsigned long boot_phys_offset,
dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
dom0_cfg.arch.nr_spis = gic_number_lines() - 32;
-dom0 = domain_create(0, _cfg);
+dom0 = domain_create(max_init_domid++, _cfg);
if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
panic("Error creating domain 0");
@@ -886,6 +890,35 @@ void __init start_xen(unsigned long boot_phys_offset,
domain_unpause_by_systemcontroller(dom0);
+chosen = dt_find_node_by_name(dt_host, "chosen");
+if ( chosen != NULL )
+{
+dt_for_each_child_node(chosen, node)
+{
+struct domain *d;
+struct xen_domctl_createdomain d_cfg = {};
There are quite a few field in xen_domctl_createdomain that we may want to
allow the user setting them. I am thinking of ssidref for XSM. How is this
going to be done?
We'll introduce a separate function to initialize the
xen_domctl_createdomain fields as necessary. I don't think it is
required at the moment?
I didn't ask the implementation but how this is going to fit together.
+
+if ( !dt_device_is_compatible(node, "xen,domU") )
+continue;
+
+d_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
Any reason to impose using the native GIC here?
It is a good default. I haven't introduced an option to change the gic
version
Re: [Xen-devel] [PATCH RFC 14/15] xen/arm: call construct_domU from start_xen and start DomU VMs
On Fri, 15 Jun 2018, Julien Grall wrote:
> On 06/13/2018 11:15 PM, Stefano Stabellini wrote:
> > Introduce support for the "xen,domU" compatible node on device tree.
> > Create new DomU VMs based on the information found on device tree under
> > "xen,domU".
>
> While I like the idea of having multiple domain created by Xen, I think there
> are still few open questions here:
> 1) The domains will be listed via "xl list". So are they still
> manageable via DOMCTL?
Yes, they are. There is an argument for making them "hidden" from
DOMCTLs, but that is not done as part of this series. Future work.
> 2) Is it possible to restart those domains?
No they can't be restarted. For example, their original kernel is gone
from memory.
> 3) If a domain crash, what will happen? Are they just going to sit
> there using resources until the platform rebooted?
The entire platform needs to be rebooted.
> 4) How do you handle scheduling? Is it still possible to do it via
> Dom0? How about the dom0less situation?
The scheduler can be chosen via the Xen command line option. It is also
possible to do that from dom0 (if there is a dom0).
> >
> > Introduce a simple global variable named max_init_domid to keep track of
> > the initial allocated domids.
>
> What is the exact goal of this new variable?
The goal of this variable is to know the number of domUs allocated at
boot time by Xen. Specifically, it is used by console.c to switch the
serial input to the right domU.
> >
> > Move the discard_initial_modules after DomUs have been built
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > xen/arch/arm/domain_build.c | 2 --
> > xen/arch/arm/setup.c| 35 ++-
> > xen/include/asm-arm/setup.h | 2 ++
> > xen/include/asm-x86/setup.h | 2 ++
>
> You need to CC x86 maintainers for this change.
I'll add them
> > 4 files changed, 38 insertions(+), 3 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 97f14ca..e2d370f 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2545,8 +2545,6 @@ int __init construct_dom0(struct domain *d)
> > if ( rc < 0 )
> > return rc;
> > -discard_initial_modules();
> > -
>
> Please mention this move in the commit message.
It is mentioned: "Move the discard_initial_modules after DomUs have been
built"
> > return __construct_domain(d, );
> > }
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 98bdb24..3723704 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -63,6 +63,8 @@ static unsigned long opt_xenheap_megabytes __initdata;
> > integer_param("xenheap_megabytes", opt_xenheap_megabytes);
> > #endif
> > +domid_t __read_mostly max_init_domid = 0;
> > +
> > static __used void init_done(void)
> > {
> > free_init_memory();
> > @@ -711,6 +713,8 @@ void __init start_xen(unsigned long boot_phys_offset,
> > struct bootmodule *xen_bootmodule;
> > struct domain *dom0;
> > struct xen_domctl_createdomain dom0_cfg = {};
> > +struct dt_device_node *chosen;
> > +struct dt_device_node *node;
> > dcache_line_bytes = read_dcache_line_bytes();
> > @@ -860,7 +864,7 @@ void __init start_xen(unsigned long boot_phys_offset,
> > dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
> > dom0_cfg.arch.nr_spis = gic_number_lines() - 32;
> > -dom0 = domain_create(0, _cfg);
> > +dom0 = domain_create(max_init_domid++, _cfg);
> > if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
> > panic("Error creating domain 0");
> > @@ -886,6 +890,35 @@ void __init start_xen(unsigned long boot_phys_offset,
> > domain_unpause_by_systemcontroller(dom0);
> > +chosen = dt_find_node_by_name(dt_host, "chosen");
> > +if ( chosen != NULL )
> > +{
> > +dt_for_each_child_node(chosen, node)
> > +{
> > +struct domain *d;
> > +struct xen_domctl_createdomain d_cfg = {};
>
> There are quite a few field in xen_domctl_createdomain that we may want to
> allow the user setting them. I am thinking of ssidref for XSM. How is this
> going to be done?
We'll introduce a separate function to initialize the
xen_domctl_createdomain fields as necessary. I don't think it is
required at the moment?
> > +
> > +if ( !dt_device_is_compatible(node, "xen,domU") )
> > +continue;
> > +
> > +d_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
>
> Any reason to impose using the native GIC here?
It is a good default. I haven't introduced an option to change the gic
version for a domU yet. It could be possible to add it in the future.
> > +d_cfg.arch.nr_spis = gic_number_lines() - 32;
>
> That's a bit unfortunate. So you are imposing to use 1020 IRQs and the waste
> of memory associated when only 32 SPIs
Re: [Xen-devel] [PATCH RFC 14/15] xen/arm: call construct_domU from start_xen and start DomU VMs
On 06/13/2018 11:15 PM, Stefano Stabellini wrote:
Introduce support for the "xen,domU" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domU".
While I like the idea of having multiple domain created by Xen, I think
there are still few open questions here:
1) The domains will be listed via "xl list". So are they still
manageable via DOMCTL?
2) Is it possible to restart those domains?
3) If a domain crash, what will happen? Are they just going to sit
there using resources until the platform rebooted?
4) How do you handle scheduling? Is it still possible to do it via
Dom0? How about the dom0less situation?
Introduce a simple global variable named max_init_domid to keep track of
the initial allocated domids.
What is the exact goal of this new variable?
Move the discard_initial_modules after DomUs have been built
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 2 --
xen/arch/arm/setup.c| 35 ++-
xen/include/asm-arm/setup.h | 2 ++
xen/include/asm-x86/setup.h | 2 ++
You need to CC x86 maintainers for this change.
4 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 97f14ca..e2d370f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2545,8 +2545,6 @@ int __init construct_dom0(struct domain *d)
if ( rc < 0 )
return rc;
-discard_initial_modules();
-
Please mention this move in the commit message.
return __construct_domain(d, );
}
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 98bdb24..3723704 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -63,6 +63,8 @@ static unsigned long opt_xenheap_megabytes __initdata;
integer_param("xenheap_megabytes", opt_xenheap_megabytes);
#endif
+domid_t __read_mostly max_init_domid = 0;
+
static __used void init_done(void)
{
free_init_memory();
@@ -711,6 +713,8 @@ void __init start_xen(unsigned long boot_phys_offset,
struct bootmodule *xen_bootmodule;
struct domain *dom0;
struct xen_domctl_createdomain dom0_cfg = {};
+struct dt_device_node *chosen;
+struct dt_device_node *node;
dcache_line_bytes = read_dcache_line_bytes();
@@ -860,7 +864,7 @@ void __init start_xen(unsigned long boot_phys_offset,
dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
dom0_cfg.arch.nr_spis = gic_number_lines() - 32;
-dom0 = domain_create(0, _cfg);
+dom0 = domain_create(max_init_domid++, _cfg);
if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
panic("Error creating domain 0");
@@ -886,6 +890,35 @@ void __init start_xen(unsigned long boot_phys_offset,
domain_unpause_by_systemcontroller(dom0);
+chosen = dt_find_node_by_name(dt_host, "chosen");
+if ( chosen != NULL )
+{
+dt_for_each_child_node(chosen, node)
+{
+struct domain *d;
+struct xen_domctl_createdomain d_cfg = {};
There are quite a few field in xen_domctl_createdomain that we may want
to allow the user setting them. I am thinking of ssidref for XSM. How is
this going to be done?
+
+if ( !dt_device_is_compatible(node, "xen,domU") )
+continue;
+
+d_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
Any reason to impose using the native GIC here?
+d_cfg.arch.nr_spis = gic_number_lines() - 32;
That's a bit unfortunate. So you are imposing to use 1020 IRQs and the
waste of memory associated when only 32 SPIs is enough at the moment.
+
+d = domain_create(max_init_domid++, _cfg);
+if ( IS_ERR(d))
Coding style ( ... )
+panic("Error creating domU");
+
+d->is_privileged = 0;
+d->target = NULL;
Why do you set them? They are zeroed by default.
+
+if ( construct_domU(d, node) != 0)
Coding style ( ... )
+printk("Could not set up DOMU guest OS");
+
+domain_unpause_by_systemcontroller(d);
+}
+}
Please introduce a new function, this would avoid to increate
start_xen() too much.
+discard_initial_modules();
+
/* Switch on to the dynamically allocated stack for the idle vcpu
* since the static one we're running on is about to be freed. */
memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(),
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index e9f9905..578f3b9 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -56,6 +56,8 @@ struct bootinfo {
extern struct bootinfo bootinfo;
+extern domid_t max_init_domid;
+
void arch_init_memory(void);
void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
diff --git a/xen/include/asm-x86/setup.h
[Xen-devel] [PATCH RFC 14/15] xen/arm: call construct_domU from start_xen and start DomU VMs
Introduce support for the "xen,domU" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domU".
Introduce a simple global variable named max_init_domid to keep track of
the initial allocated domids.
Move the discard_initial_modules after DomUs have been built
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 2 --
xen/arch/arm/setup.c| 35 ++-
xen/include/asm-arm/setup.h | 2 ++
xen/include/asm-x86/setup.h | 2 ++
4 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 97f14ca..e2d370f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2545,8 +2545,6 @@ int __init construct_dom0(struct domain *d)
if ( rc < 0 )
return rc;
-discard_initial_modules();
-
return __construct_domain(d, );
}
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 98bdb24..3723704 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -63,6 +63,8 @@ static unsigned long opt_xenheap_megabytes __initdata;
integer_param("xenheap_megabytes", opt_xenheap_megabytes);
#endif
+domid_t __read_mostly max_init_domid = 0;
+
static __used void init_done(void)
{
free_init_memory();
@@ -711,6 +713,8 @@ void __init start_xen(unsigned long boot_phys_offset,
struct bootmodule *xen_bootmodule;
struct domain *dom0;
struct xen_domctl_createdomain dom0_cfg = {};
+struct dt_device_node *chosen;
+struct dt_device_node *node;
dcache_line_bytes = read_dcache_line_bytes();
@@ -860,7 +864,7 @@ void __init start_xen(unsigned long boot_phys_offset,
dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
dom0_cfg.arch.nr_spis = gic_number_lines() - 32;
-dom0 = domain_create(0, _cfg);
+dom0 = domain_create(max_init_domid++, _cfg);
if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
panic("Error creating domain 0");
@@ -886,6 +890,35 @@ void __init start_xen(unsigned long boot_phys_offset,
domain_unpause_by_systemcontroller(dom0);
+chosen = dt_find_node_by_name(dt_host, "chosen");
+if ( chosen != NULL )
+{
+dt_for_each_child_node(chosen, node)
+{
+struct domain *d;
+struct xen_domctl_createdomain d_cfg = {};
+
+if ( !dt_device_is_compatible(node, "xen,domU") )
+continue;
+
+d_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
+d_cfg.arch.nr_spis = gic_number_lines() - 32;
+
+d = domain_create(max_init_domid++, _cfg);
+if ( IS_ERR(d))
+panic("Error creating domU");
+
+d->is_privileged = 0;
+d->target = NULL;
+
+if ( construct_domU(d, node) != 0)
+printk("Could not set up DOMU guest OS");
+
+domain_unpause_by_systemcontroller(d);
+}
+}
+discard_initial_modules();
+
/* Switch on to the dynamically allocated stack for the idle vcpu
* since the static one we're running on is about to be freed. */
memcpy(idle_vcpu[0]->arch.cpu_info, get_cpu_info(),
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index e9f9905..578f3b9 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -56,6 +56,8 @@ struct bootinfo {
extern struct bootinfo bootinfo;
+extern domid_t max_init_domid;
+
void arch_init_memory(void);
void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
diff --git a/xen/include/asm-x86/setup.h b/xen/include/asm-x86/setup.h
index 19232af..2fb9529 100644
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -73,4 +73,6 @@ extern bool opt_dom0_shadow;
#endif
extern bool dom0_pvh;
+#define max_init_domid (1)
+
#endif
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
