Add three properties, memory, mem-min, and mem-max, to the domain node device
tree parsing to define the memory allocation for a domain. All three fields are
expressed in kb and written as a u64 in the device tree entries.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
---
xen/arch/x86/dom0_build.c | 8 ++++++
xen/arch/x86/domain_builder/fdt.c | 37 +++++++++++++++++++++++++++
xen/arch/x86/domain_builder/fdt.h | 9 +++++++
xen/arch/x86/include/asm/bootdomain.h | 4 +++
4 files changed, 58 insertions(+)
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index c231191faec7..1c3b7ff0e658 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -609,6 +609,14 @@ int __init construct_dom0(struct boot_domain *bd)
process_pending_softirqs();
+ /* If param dom0_size was not set and HL config provided memory size */
+ if ( !get_memsize(&dom0_size, LONG_MAX) && bd->mem_pages )
+ dom0_size.nr_pages = bd->mem_pages;
+ if ( !get_memsize(&dom0_min_size, LONG_MAX) && bd->min_pages )
+ dom0_size.nr_pages = bd->min_pages;
+ if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages )
+ dom0_size.nr_pages = bd->max_pages;
+
if ( is_hvm_domain(d) )
rc = dom0_construct_pvh(bd);
else if ( is_pv_domain(d) )
diff --git a/xen/arch/x86/domain_builder/fdt.c b/xen/arch/x86/domain_builder/fdt.c
index 09e72d96a752..b8ace5c18c6a 100644
--- a/xen/arch/x86/domain_builder/fdt.c
+++ b/xen/arch/x86/domain_builder/fdt.c
@@ -7,6 +7,7 @@
#include <xen/lib.h>
#include <xen/libfdt/libfdt.h>
#include <xen/rangeset.h> /* required for asm/setup.h */
+#include <xen/sizes.h>
#include <asm/bootinfo.h>
#include <asm/guest.h>
@@ -160,6 +161,42 @@ static int __init process_domain_node(
else
printk("PV\n");
}
+ if ( match_fdt_property(fdt, prop, "memory" ) )
+ {
+ uint64_t kb;
+ if ( fdt_prop_as_u64(prop, &kb) != 0 )
+ {
+ printk(" failed processing memory for domain %s\n",
+ name == NULL ? "unknown" : name);
+ return -EINVAL;
+ }
+ bd->mem_pages = PFN_DOWN(kb * SZ_1K);
+ printk(" memory: %ld\n", bd->mem_pages << PAGE_SHIFT);
+ }
+ if ( match_fdt_property(fdt, prop, "mem-min" ) )
+ {
+ uint64_t kb;
+ if ( fdt_prop_as_u64(prop, &kb) != 0 )
+ {
+ printk(" failed processing memory for domain %s\n",
+ name == NULL ? "unknown" : name);
+ return -EINVAL;
+ }
+ bd->min_pages = PFN_DOWN(kb * SZ_1K);
+ printk(" min memory: %ld\n", bd->min_pages << PAGE_SHIFT);
+ }
+ if ( match_fdt_property(fdt, prop, "mem-max" ) )
+ {
+ uint64_t kb;
+ if ( fdt_prop_as_u64(prop, &kb) != 0 )
+ {
+ printk(" failed processing memory for domain %s\n",
+ name == NULL ? "unknown" : name);
+ return -EINVAL;
+ }
+ bd->max_pages = PFN_DOWN(kb * SZ_1K);
+ printk(" max memory: %ld\n", bd->max_pages << PAGE_SHIFT);
+ }
}
fdt_for_each_subnode(node, fdt, dom_node)
diff --git a/xen/arch/x86/domain_builder/fdt.h b/xen/arch/x86/domain_builder/fdt.h
index 06ead05a2583..73d02019b3c7 100644
--- a/xen/arch/x86/domain_builder/fdt.h
+++ b/xen/arch/x86/domain_builder/fdt.h
@@ -36,6 +36,15 @@ static inline int __init fdt_prop_as_u32(
return fdt_cell_as_u32((fdt32_t *)prop->data, val);
}
+static inline int __init fdt_prop_as_u64(
+ const struct fdt_property *prop, uint64_t *val)
+{
+ if ( !prop || fdt32_to_cpu(prop->len) < sizeof(u64) )
+ return -EINVAL;
+
+ return fdt_cell_as_u64((fdt32_t *)prop->data, val);
+}
+
static inline bool __init match_fdt_property(
const void *fdt, const struct fdt_property *prop, const char *s)
{
diff --git a/xen/arch/x86/include/asm/bootdomain.h b/xen/arch/x86/include/asm/bootdomain.h
index 50c33d183e07..9a5ba2931665 100644
--- a/xen/arch/x86/include/asm/bootdomain.h
+++ b/xen/arch/x86/include/asm/bootdomain.h
@@ -24,6 +24,10 @@ struct boot_domain {
#define BUILD_MODE_LONG (1 << 2) /* 64 BIT | 32 BIT */
uint32_t mode;
+ unsigned long mem_pages;
+ unsigned long min_pages;
+ unsigned long max_pages;
+
struct boot_module *kernel;
struct boot_module *ramdisk;
--
2.30.2On 23.11.2024 19:20, Daniel P. Smith wrote:
> @@ -160,6 +161,42 @@ static int __init process_domain_node(
> else
> printk("PV\n");
> }
> + if ( match_fdt_property(fdt, prop, "memory" ) )
> + {
> + uint64_t kb;
> + if ( fdt_prop_as_u64(prop, &kb) != 0 )
> + {
> + printk(" failed processing memory for domain %s\n",
> + name == NULL ? "unknown" : name);
> + return -EINVAL;
> + }
> + bd->mem_pages = PFN_DOWN(kb * SZ_1K);
> + printk(" memory: %ld\n", bd->mem_pages << PAGE_SHIFT);
> + }
> + if ( match_fdt_property(fdt, prop, "mem-min" ) )
> + {
> + uint64_t kb;
> + if ( fdt_prop_as_u64(prop, &kb) != 0 )
> + {
> + printk(" failed processing memory for domain %s\n",
> + name == NULL ? "unknown" : name);
> + return -EINVAL;
> + }
> + bd->min_pages = PFN_DOWN(kb * SZ_1K);
> + printk(" min memory: %ld\n", bd->min_pages << PAGE_SHIFT);
> + }
> + if ( match_fdt_property(fdt, prop, "mem-max" ) )
> + {
> + uint64_t kb;
> + if ( fdt_prop_as_u64(prop, &kb) != 0 )
> + {
> + printk(" failed processing memory for domain %s\n",
> + name == NULL ? "unknown" : name);
> + return -EINVAL;
> + }
> + bd->max_pages = PFN_DOWN(kb * SZ_1K);
> + printk(" max memory: %ld\n", bd->max_pages << PAGE_SHIFT);
> + }
Since the values logged are all multiples of 1k, why make reading the logs
more complicated by logging byte-granular values? I instead wonder whether
converting to more coarse grained values (leaving, say, between 4 and 6
significant digits while using kb, Mb, Gb, etc) wouldn't be yet better.
Jan
On 12/2/24 07:14, Jan Beulich wrote:
> On 23.11.2024 19:20, Daniel P. Smith wrote:
>> @@ -160,6 +161,42 @@ static int __init process_domain_node(
>> else
>> printk("PV\n");
>> }
>> + if ( match_fdt_property(fdt, prop, "memory" ) )
>> + {
>> + uint64_t kb;
>> + if ( fdt_prop_as_u64(prop, &kb) != 0 )
>> + {
>> + printk(" failed processing memory for domain %s\n",
>> + name == NULL ? "unknown" : name);
>> + return -EINVAL;
>> + }
>> + bd->mem_pages = PFN_DOWN(kb * SZ_1K);
>> + printk(" memory: %ld\n", bd->mem_pages << PAGE_SHIFT);
>> + }
>> + if ( match_fdt_property(fdt, prop, "mem-min" ) )
>> + {
>> + uint64_t kb;
>> + if ( fdt_prop_as_u64(prop, &kb) != 0 )
>> + {
>> + printk(" failed processing memory for domain %s\n",
>> + name == NULL ? "unknown" : name);
>> + return -EINVAL;
>> + }
>> + bd->min_pages = PFN_DOWN(kb * SZ_1K);
>> + printk(" min memory: %ld\n", bd->min_pages << PAGE_SHIFT);
>> + }
>> + if ( match_fdt_property(fdt, prop, "mem-max" ) )
>> + {
>> + uint64_t kb;
>> + if ( fdt_prop_as_u64(prop, &kb) != 0 )
>> + {
>> + printk(" failed processing memory for domain %s\n",
>> + name == NULL ? "unknown" : name);
>> + return -EINVAL;
>> + }
>> + bd->max_pages = PFN_DOWN(kb * SZ_1K);
>> + printk(" max memory: %ld\n", bd->max_pages << PAGE_SHIFT);
>> + }
>
> Since the values logged are all multiples of 1k, why make reading the logs
> more complicated by logging byte-granular values? I instead wonder whether
> converting to more coarse grained values (leaving, say, between 4 and 6
> significant digits while using kb, Mb, Gb, etc) wouldn't be yet better.
Sure we can make it report in a friendlier format. To support dynamic
sizing, is there already an existing formatter, I would hate to
re-invent the wheel on this, or I could just statically report in kb.
v/r,
dps
On 11.12.2024 19:02, Daniel P. Smith wrote:
> On 12/2/24 07:14, Jan Beulich wrote:
>> On 23.11.2024 19:20, Daniel P. Smith wrote:
>>> @@ -160,6 +161,42 @@ static int __init process_domain_node(
>>> else
>>> printk("PV\n");
>>> }
>>> + if ( match_fdt_property(fdt, prop, "memory" ) )
>>> + {
>>> + uint64_t kb;
>>> + if ( fdt_prop_as_u64(prop, &kb) != 0 )
>>> + {
>>> + printk(" failed processing memory for domain %s\n",
>>> + name == NULL ? "unknown" : name);
>>> + return -EINVAL;
>>> + }
>>> + bd->mem_pages = PFN_DOWN(kb * SZ_1K);
>>> + printk(" memory: %ld\n", bd->mem_pages << PAGE_SHIFT);
>>> + }
>>> + if ( match_fdt_property(fdt, prop, "mem-min" ) )
>>> + {
>>> + uint64_t kb;
>>> + if ( fdt_prop_as_u64(prop, &kb) != 0 )
>>> + {
>>> + printk(" failed processing memory for domain %s\n",
>>> + name == NULL ? "unknown" : name);
>>> + return -EINVAL;
>>> + }
>>> + bd->min_pages = PFN_DOWN(kb * SZ_1K);
>>> + printk(" min memory: %ld\n", bd->min_pages << PAGE_SHIFT);
>>> + }
>>> + if ( match_fdt_property(fdt, prop, "mem-max" ) )
>>> + {
>>> + uint64_t kb;
>>> + if ( fdt_prop_as_u64(prop, &kb) != 0 )
>>> + {
>>> + printk(" failed processing memory for domain %s\n",
>>> + name == NULL ? "unknown" : name);
>>> + return -EINVAL;
>>> + }
>>> + bd->max_pages = PFN_DOWN(kb * SZ_1K);
>>> + printk(" max memory: %ld\n", bd->max_pages << PAGE_SHIFT);
>>> + }
>>
>> Since the values logged are all multiples of 1k, why make reading the logs
>> more complicated by logging byte-granular values? I instead wonder whether
>> converting to more coarse grained values (leaving, say, between 4 and 6
>> significant digits while using kb, Mb, Gb, etc) wouldn't be yet better.
>
> Sure we can make it report in a friendlier format. To support dynamic
> sizing, is there already an existing formatter, I would hate to
> re-invent the wheel on this, or I could just statically report in kb.
I don't recall use having any formatter for this, so for now I'd just report
kb values.
Jan
On 2024-11-23 13:20, Daniel P. Smith wrote: > Add three properties, memory, mem-min, and mem-max, to the domain node device > tree parsing to define the memory allocation for a domain. All three fields are > expressed in kb and written as a u64 in the device tree entries. > > Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> > --- > diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c > index c231191faec7..1c3b7ff0e658 100644 > --- a/xen/arch/x86/dom0_build.c > +++ b/xen/arch/x86/dom0_build.c > @@ -609,6 +609,14 @@ int __init construct_dom0(struct boot_domain *bd) > > process_pending_softirqs(); > > + /* If param dom0_size was not set and HL config provided memory size */ > + if ( !get_memsize(&dom0_size, LONG_MAX) && bd->mem_pages ) > + dom0_size.nr_pages = bd->mem_pages; > + if ( !get_memsize(&dom0_min_size, LONG_MAX) && bd->min_pages ) > + dom0_size.nr_pages = bd->min_pages; > + if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages ) > + dom0_size.nr_pages = bd->max_pages; > + This placement seems a little random. Can this move into dom0_compute_nr_pages()? > if ( is_hvm_domain(d) ) > rc = dom0_construct_pvh(bd); > else if ( is_pv_domain(d) )
On 11/25/24 19:03, Jason Andryuk wrote: > On 2024-11-23 13:20, Daniel P. Smith wrote: >> Add three properties, memory, mem-min, and mem-max, to the domain node >> device >> tree parsing to define the memory allocation for a domain. All three >> fields are >> expressed in kb and written as a u64 in the device tree entries. >> >> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> >> --- > >> diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c >> index c231191faec7..1c3b7ff0e658 100644 >> --- a/xen/arch/x86/dom0_build.c >> +++ b/xen/arch/x86/dom0_build.c >> @@ -609,6 +609,14 @@ int __init construct_dom0(struct boot_domain *bd) >> process_pending_softirqs(); >> + /* If param dom0_size was not set and HL config provided memory >> size */ >> + if ( !get_memsize(&dom0_size, LONG_MAX) && bd->mem_pages ) >> + dom0_size.nr_pages = bd->mem_pages; >> + if ( !get_memsize(&dom0_min_size, LONG_MAX) && bd->min_pages ) >> + dom0_size.nr_pages = bd->min_pages; >> + if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages ) >> + dom0_size.nr_pages = bd->max_pages; >> + > > This placement seems a little random. Can this move into > dom0_compute_nr_pages()? As I started to rebase the multi-domain code around all the changes that happened under the boot module review, dom0_compute_nr_pages() became a mess to work with again. The result does see this drop in favor of handling during dom_compute_nr_pages(). I will look to back port that refactoring to here. v/r, dps
On 12/11/24 12:59, Daniel P. Smith wrote: > On 11/25/24 19:03, Jason Andryuk wrote: >> On 2024-11-23 13:20, Daniel P. Smith wrote: >>> Add three properties, memory, mem-min, and mem-max, to the domain >>> node device >>> tree parsing to define the memory allocation for a domain. All three >>> fields are >>> expressed in kb and written as a u64 in the device tree entries. >>> >>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> >>> --- >> >>> diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c >>> index c231191faec7..1c3b7ff0e658 100644 >>> --- a/xen/arch/x86/dom0_build.c >>> +++ b/xen/arch/x86/dom0_build.c >>> @@ -609,6 +609,14 @@ int __init construct_dom0(struct boot_domain *bd) >>> process_pending_softirqs(); >>> + /* If param dom0_size was not set and HL config provided memory >>> size */ >>> + if ( !get_memsize(&dom0_size, LONG_MAX) && bd->mem_pages ) >>> + dom0_size.nr_pages = bd->mem_pages; >>> + if ( !get_memsize(&dom0_min_size, LONG_MAX) && bd->min_pages ) >>> + dom0_size.nr_pages = bd->min_pages; >>> + if ( !get_memsize(&dom0_max_size, LONG_MAX) && bd->max_pages ) >>> + dom0_size.nr_pages = bd->max_pages; >>> + >> >> This placement seems a little random. Can this move into >> dom0_compute_nr_pages()? > > As I started to rebase the multi-domain code around all the changes that > happened under the boot module review, dom0_compute_nr_pages() became a > mess to work with again. The result does see this drop in favor of > handling during dom_compute_nr_pages(). I will look to back port that > refactoring to here. Before sending out v2, wanted to respond back that I did not see an immediate way to move this up to dom0_compute_nr_pages() without bring in a series of unrelated changes. v/r, dps
© 2016 - 2024 Red Hat, Inc.