[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 13/15] x86/hyperlaunch: add memory parsing to domain config
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 11 Dec 2024 13:02:10 -0500
- Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1733940134; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=6tzOCB89aUMmzBNvnrv96m1H59rEhkXoYmeGsgmxwq8=; b=P3x++HkO5+FzxFFA9caBeyH0sKVyJ7ayxAEaZeQVQzcLSBMBisKMVbFrig229fEXIoGS19QPXM5SAirzVD+FuKpv8Rl42M/82OQPI2qa6FPJzkzSlsMRH9WuyiGLxdvwP2ocsMuyBeppMJG+k2jXGa6g08NexKWXVCiHE27jMmI=
- Arc-seal: i=1; a=rsa-sha256; t=1733940134; cv=none; d=zohomail.com; s=zohoarc; b=cLb54D+K610+OOP8NztLm8oHUXh7WGG8bqJx80S7L6Yg/sLBRfiBcrx2Z9WBRfVChYE1QNqFuFairNPwR3REZ80I+JcIjcT0DsDxaKFMubcNeD1AX28em+M5ZQ35y2tB4Ngq1RwIQ48bp6wELNdKEJZrTe/yAVqjuMXd6Cc5DPo=
- Cc: jason.andryuk@xxxxxxx, christopher.w.clark@xxxxxxxxx, stefano.stabellini@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Wed, 11 Dec 2024 18:02:23 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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
|
