From: Penny Zheng <Penny.Zheng@arm.com>
To: Julien Grall <julien@xen.org>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"sstabellini@kernel.org" <sstabellini@kernel.org>,
"jbeulich@suse.com" <jbeulich@suse.com>
Cc: Bertrand Marquis <Bertrand.Marquis@arm.com>, Wei Chen <Wei.Chen@arm.com>
Subject: RE: [PATCH 8/9] xen/arm: check `xen,static-mem` property during domain construction
Date: Tue, 6 Jul 2021 06:31:18 +0000 [thread overview]
Message-ID: <VE1PR08MB52155D35A7B716DC7337311DF71B9@VE1PR08MB5215.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <f613372a-eac8-f79b-2941-b7cce3e1e0e7@xen.org>
Hi
> -----Original Message-----
> From: Julien Grall <julien@xen.org>
> Sent: Saturday, July 3, 2021 9:26 PM
> To: Penny Zheng <Penny.Zheng@arm.com>; xen-devel@lists.xenproject.org;
> sstabellini@kernel.org; jbeulich@suse.com
> Cc: Bertrand Marquis <Bertrand.Marquis@arm.com>; Wei Chen
> <Wei.Chen@arm.com>
> Subject: Re: [PATCH 8/9] xen/arm: check `xen,static-mem` property during
> domain construction
>
> Hi Penny,
>
> On 07/06/2021 03:43, Penny Zheng wrote:
> > This commit checks `xen,static-mem` device tree property in /domUx
> > node, to determine whether domain is on Static Allocation, when
> > constructing domain during boot-up.
> >
> > Right now, the implementation of allocate_static_memory is missing,
> > and will be introduced later. It just BUG() out at the moment.
> >
> > And if the `memory` property and `xen,static-mem` are both set, it
> > shall be verified that if the memory size defined in both is consistent.
> >
> > Signed-off-by: Penny Zheng <penny.zheng@arm.com>
> > ---
> > changes v2:
> > - remove parsing procedure here
> > - check the consistency when `xen,static-mem` and `memory` are both
> > defined
> > ---
> > xen/arch/arm/domain_build.c | 37 +++++++++++++++++++++++++++++++---
> ---
> > 1 file changed, 31 insertions(+), 6 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 282416e74d..4166d7993c 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2424,23 +2424,47 @@ static int __init construct_domU(struct domain
> *d,
> > {
> > struct kernel_info kinfo = {};
> > int rc;
> > - u64 mem;
> > + u64 mem, static_mem_size = 0;
> > + const struct dt_property *prop;
> > + bool static_mem = false;
> > +
> > + d->max_pages = ~0U;
> > + /*
> > + * Guest RAM could be of static memory from static allocation,
> > + * which will be specified through "xen,static-mem" phandle.
> > + */
> > + prop = dt_find_property(node, "xen,static-mem", NULL);
> > + if ( prop )
> > + {
> > + static_mem = true;
> > + /* static_mem_size = allocate_static_memory(...); */
> > + BUG();
> > + }
>
> I would prefer if the static memory is allocated close to
> allocate_memory() below. AFAICT, the reason you allocate here is because you
> want to have the property "memory" optional.
>
> However, I am not entirely convinced this is a good idea to make optional. It
> would be easier for a reader to figure out from the device-tree how much
> memory we give to the guest.
>
Hmmm, now I think maybe I understand wrongly what you suggested in v1.
"
Could we allocate the memory as we parse?
"
I just simply think it means the code sequence, putting allocation immediately
after parsing. ;/
Re-investigating the docs on "memory":
"
- memory
A 64-bit integer specifying the amount of kilobytes of RAM to
allocate to the guest.
"
If you prefer "memory" mandate, then tbh, it will make the code
here more easily-read, no ifs.
But maybe I shall put more info on docs to clarify that even though user using
"xen, static-mem" to refer to static memory allocation, they shall still use
"memory" property to tell how much memory we give to the guest.
> >
> > rc = dt_property_read_u64(node, "memory", &mem);
> > - if ( !rc )
> > + if ( !static_mem && !rc )
> > {
> > printk("Error building DomU: cannot read \"memory\" property\n");
> > return -EINVAL;
> > + } else if ( rc && static_mem )
> > + {
> > + if ( static_mem_size != mem * SZ_1K )
> > + {
> > + printk("Memory size in \"memory\" property isn't consistent with"
> > + "the ones defined in \"xen,static-mem\".\n");
> > + return -EINVAL;
> > + }
> > } > - kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
> > + kinfo.unassigned_mem = static_mem ? 0 : (paddr_t)mem * SZ_1K; >
> > - printk("*** LOADING DOMU cpus=%u memory=%"PRIx64"KB ***\n", d-
> >max_vcpus, mem);
> > + printk("*** LOADING DOMU cpus=%u memory=%"PRIx64"KB ***\n",
> > + d->max_vcpus,
> > + static_mem ? static_mem_size : (kinfo.unassigned_mem) >>
> > + 10);
>
>
> If we mandate the property "memory", then kinfo.unassigned_mem doesn't
> need to be touched. Instead, you could simply check the
> kinfo.unassigned_mem is equivalent to static_mem_size.
>
True, true.
> >
> > kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
> >
> > if ( vcpu_create(d, 0) == NULL )
> > return -ENOMEM;
> > - d->max_pages = ~0U;
> >
> > kinfo.d = d;
> >
> > @@ -2452,7 +2476,8 @@ static int __init construct_domU(struct domain *d,
> > /* type must be set before allocate memory */
> > d->arch.type = kinfo.type;
> > #endif
> > - allocate_memory(d, &kinfo);
> > + if ( !static_mem )
> > + allocate_memory(d, &kinfo);
> >
> > rc = prepare_dtb_domU(d, &kinfo);
> > if ( rc < 0 )
> >
>
> Cheers,
>
> --
> Julien Grall
Cheers,
--
Penny Zheng
next prev parent reply other threads:[~2021-07-06 6:32 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-07 2:43 [PATCH V2 0/9] Domain on Static Allocation Penny Zheng
2021-06-07 2:43 ` [PATCH 1/9] xen/arm: introduce domain " Penny Zheng
2021-06-07 2:43 ` [PATCH 2/9] xen/arm: introduce PGC_reserved Penny Zheng
2021-06-30 17:44 ` Julien Grall
2021-07-05 3:09 ` Penny Zheng
2021-06-07 2:43 ` [PATCH 3/9] xen/arm: introduce CONFIG_STATIC_ALLOCATION Penny Zheng
2021-06-07 6:17 ` Jan Beulich
2021-06-30 17:45 ` Julien Grall
2021-07-05 3:16 ` Penny Zheng
2021-06-07 2:43 ` [PATCH 4/9] xen/arm: static memory initialization Penny Zheng
2021-06-10 9:35 ` Jan Beulich
2021-06-30 17:46 ` Julien Grall
2021-07-05 5:22 ` Penny Zheng
2021-07-05 7:14 ` Penny Zheng
2021-07-05 7:50 ` Jan Beulich
2021-07-05 9:19 ` Penny Zheng
2021-07-05 7:48 ` Jan Beulich
2021-06-30 18:09 ` Julien Grall
2021-07-05 7:28 ` Penny Zheng
2021-07-06 9:09 ` Julien Grall
2021-07-06 9:20 ` Penny Zheng
2021-07-06 9:26 ` Julien Grall
2021-06-07 2:43 ` [PATCH 5/9] xen: introduce assign_pages_nr Penny Zheng
2021-06-10 9:49 ` Jan Beulich
2021-06-30 18:29 ` Julien Grall
2021-07-01 8:26 ` Jan Beulich
2021-07-01 9:24 ` Julien Grall
2021-07-01 10:13 ` Jan Beulich
2021-06-07 2:43 ` [PATCH 6/9] xen/arm: introduce alloc_staticmem_pages and alloc_domstatic_pages Penny Zheng
2021-06-10 10:23 ` Jan Beulich
2021-07-06 5:58 ` Penny Zheng
2021-07-06 6:53 ` Jan Beulich
2021-07-06 9:39 ` Julien Grall
2021-07-06 9:59 ` Jan Beulich
2021-07-06 10:31 ` Julien Grall
2021-07-08 9:09 ` Penny Zheng
2021-07-08 10:06 ` Jan Beulich
2021-07-08 11:07 ` Penny Zheng
2021-06-07 2:43 ` [PATCH 7/9] xen/arm: take care of concurrency on static memory allocation Penny Zheng
2021-06-10 10:53 ` Jan Beulich
2021-06-07 2:43 ` [PATCH 8/9] xen/arm: check `xen,static-mem` property during domain construction Penny Zheng
2021-07-03 13:26 ` Julien Grall
2021-07-06 6:31 ` Penny Zheng [this message]
2021-07-06 6:57 ` Jan Beulich
2021-07-06 7:35 ` Penny Zheng
2021-07-06 9:22 ` Julien Grall
2021-06-07 2:43 ` [PATCH 9/9] xen/arm: introduce allocate_static_memory Penny Zheng
2021-07-03 14:18 ` Julien Grall
2021-07-06 7:30 ` Penny Zheng
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=VE1PR08MB52155D35A7B716DC7337311DF71B9@VE1PR08MB5215.eurprd08.prod.outlook.com \
--to=penny.zheng@arm.com \
--cc=Bertrand.Marquis@arm.com \
--cc=Wei.Chen@arm.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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.