From: Jan Beulich <jbeulich@suse.com>
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
stefano.stabellini@amd.com,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH 08/15] x86/hyperlaunch: locate dom0 kernel with hyperlaunch
Date: Mon, 2 Dec 2024 12:53:18 +0100 [thread overview]
Message-ID: <91e6d4e7-b4ff-4e13-8814-95eaac891cf4@suse.com> (raw)
In-Reply-To: <20241123182044.30687-9-dpsmith@apertussolutions.com>
On 23.11.2024 19:20, Daniel P. Smith wrote:
> Look for a subnode of type `multiboot,kernel` within a domain node. If found,
> process the reg property for the MB1 module index. If the bootargs property is
> present and there was not an MB1 string, then use the command line from the
> device tree definition.
Why specifically MB1?
> --- a/xen/arch/x86/domain_builder/core.c
> +++ b/xen/arch/x86/domain_builder/core.c
> @@ -56,6 +56,18 @@ void __init builder_init(struct boot_info *bi)
>
> printk(XENLOG_INFO " Number of domains: %d\n", bi->nr_domains);
> }
> + else
> + {
> + int i;
Plain int when ...
> + /* Find first unknown boot module to use as Dom0 kernel */
> + printk("Falling back to using first boot module as dom0\n");
> + i = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
> + bi->mods[i].type = BOOTMOD_KERNEL;
> + bi->domains[0].kernel = &bi->mods[i];
> + bi->nr_domains = 1;
> + }
... it's used as array index (and there's no check for the function return
value being negative)?
> --- a/xen/arch/x86/domain_builder/fdt.c
> +++ b/xen/arch/x86/domain_builder/fdt.c
> @@ -14,6 +14,122 @@
>
> #include "fdt.h"
>
> +static inline int __init fdt_get_prop_as_reg(
What does "reg" stand for here?
> + const void *fdt, int node, const char *name, unsigned int ssize,
> + unsigned int asize, uint64_t *size, uint64_t *addr)
> +{
> + int ret;
> + const struct fdt_property *prop;
> + fdt32_t *cell;
> +
> + /* FDT spec max size is 4 (128bit int), but largest arch int size is 64 */
> + if ( ssize > 2 || asize > 2 )
> + return -EINVAL;
> +
> + prop = fdt_get_property(fdt, node, name, &ret);
> + if ( !prop || ret < sizeof(u32) )
> + return ret < 0 ? ret : -EINVAL;
> +
> + /* read address field */
> + cell = (fdt32_t *)prop->data;
> +
> + if ( asize == 1 )
> + {
> + uint32_t val;
> + fdt_cell_as_u32(cell, &val);
> + *addr = (uint64_t)val;
No need for a cast here nor ...
> + }
> + else
> + fdt_cell_as_u64(cell, addr);
> +
> + /* read size field */
> + cell += asize;
> +
> + if ( ssize == 1 )
> + {
> + uint32_t val;
> + fdt_cell_as_u32(cell, &val);
> + *size = (uint64_t)val;
... here?
> + }
> + else
> + fdt_cell_as_u64(cell, size);
> +
> + return 0;
> +}
This whole function reads very much like a library one. Does it really need
adding here, rather than to the FDT library code we already have? In any
event there's nothing x86-specific about it, afaics.
> +static int __init dom0less_module_node(
> + void *fdt, int node, int size_size, int address_size)
Three times plain int, when ...
> +{
> + uint64_t size, addr;
> + int ret = fdt_get_prop_as_reg(fdt, node, "reg", size_size, address_size,
... two get converted to unsigned int in the course of the function call
here?
> + &size, &addr);
> + /* An FDT error value may have been returned, translate to -EINVAL */
> + if ( ret < 0 )
> + return -EINVAL;
> +
> + if ( size != 0 )
> + return -EOPNOTSUPP;
Not knowing much about DT: What does 0 represent here?
> + if ( addr > MAX_NR_BOOTMODS )
> + return -ERANGE;
> +
> + /*
> + * MAX_NR_BOOTMODS cannot exceed the max for MB1, represented by a u32,
> + * thus the cast down to a u32 will be safe due to the prior check.
> + */
> + return (int)addr;
Comment and cast contradict one another. DYM u32 (really: uint32_t), or plain
int? If you mean to return a plain int (for the sake of the -errno values
further up), MAX_NR_BOOTMODS needs to stay below 2**31.
> +static int __init process_domain_node(
> + struct boot_info *bi, void *fdt, int dom_node)
> +{
> + int node;
> + struct boot_domain *bd = &bi->domains[bi->nr_domains];
> + const char *name = fdt_get_name(fdt, dom_node, NULL);
> + int address_size = fdt_address_cells(fdt, dom_node);
> + int size_size = fdt_size_cells(fdt, dom_node);
> +
> + if ( address_size < 0 || size_size < 0 )
> + {
> + printk(" failed processing #address or #size for domain %s)\n",
> + name == NULL ? "unknown" : name);
> + return -EINVAL;
> + }
> +
> + fdt_for_each_subnode(node, fdt, dom_node)
> + {
> + if ( fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
> + {
> + int idx = dom0less_module_node(fdt, node, size_size, address_size);
> + if ( idx < 0 )
> + {
> + printk(" failed processing kernel module for domain %s)\n",
> + name == NULL ? "unknown" : name);
> + return idx;
> + }
> +
> + if ( idx > bi->nr_modules )
> + {
> + printk(" invalid kernel module index for domain node (%d)\n",
> + bi->nr_domains);
> + return -EINVAL;
> + }
> +
> + printk(" kernel: boot module %d\n", idx);
> + bi->mods[idx].type = BOOTMOD_KERNEL;
> + bd->kernel = &bi->mods[idx];
> + }
> + }
What if you find two?
> --- a/xen/arch/x86/domain_builder/fdt.h
> +++ b/xen/arch/x86/domain_builder/fdt.h
> @@ -3,6 +3,7 @@
> #define __XEN_X86_FDT_H__
>
> #include <xen/init.h>
> +#include <xen/libfdt/libfdt.h>
>
> #include <asm/bootinfo.h>
>
> @@ -10,6 +11,22 @@
> #define HYPERLAUNCH_MODULE_IDX 0
>
> #ifdef CONFIG_DOMAIN_BUILDER
> +
> +static inline int __init fdt_cell_as_u32(const fdt32_t *cell, uint32_t *val)
> +{
> + *val = fdt32_to_cpu(*cell);
> +
> + return 0;
> +}
> +
> +static inline int __init fdt_cell_as_u64(const fdt32_t *cell, uint64_t *val)
> +{
> + *val = ((uint64_t)fdt32_to_cpu(cell[0]) << 32) |
> + (uint64_t)fdt32_to_cpu(cell[1]);
> +
> + return 0;
> +}
Basic library routines again?
Jan
next prev parent reply other threads:[~2024-12-02 11:53 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-23 18:20 [PATCH 00/15] Hyperlaunch device tree for dom0 Daniel P. Smith
2024-11-23 18:20 ` [PATCH 01/15] x86/boot: introduce boot domain Daniel P. Smith
2024-12-02 9:57 ` Jan Beulich
2024-12-04 19:16 ` Daniel P. Smith
2024-11-23 18:20 ` [PATCH 02/15] x86/boot: introduce domid field to struct boot_domain Daniel P. Smith
2024-11-23 18:20 ` [PATCH 03/15] x86/boot: add cmdline " Daniel P. Smith
2024-11-25 15:36 ` Jason Andryuk
2024-12-11 2:56 ` Daniel P. Smith
2024-12-02 9:49 ` Jan Beulich
2024-12-11 3:01 ` Daniel P. Smith
2024-11-23 18:20 ` [PATCH 04/15] kconfig: introduce option to independently enable libfdt Daniel P. Smith
2024-11-25 15:42 ` Jason Andryuk
2024-12-11 3:03 ` Daniel P. Smith
2024-11-26 10:03 ` Jan Beulich
2024-11-26 10:05 ` Jan Beulich
2024-12-11 3:05 ` Daniel P. Smith
2024-12-11 3:04 ` Daniel P. Smith
2024-11-23 18:20 ` [PATCH 05/15] kconfig: introduce domain builder config option Daniel P. Smith
2024-11-25 17:55 ` Jason Andryuk
2024-12-11 3:13 ` Daniel P. Smith
2024-11-26 10:09 ` Jan Beulich
2024-12-11 3:15 ` Daniel P. Smith
2024-11-23 18:20 ` [PATCH 06/15] x86/hyperlaunch: introduce the domain builder Daniel P. Smith
2024-11-25 17:52 ` Jason Andryuk
2024-11-25 20:23 ` Jason Andryuk
2024-12-02 9:55 ` Jan Beulich
2024-12-02 15:31 ` Jason Andryuk
2024-12-11 11:14 ` Daniel P. Smith
2024-12-02 10:10 ` Jan Beulich
2024-12-11 12:36 ` Daniel P. Smith
2024-12-12 11:06 ` Jan Beulich
2024-12-12 15:24 ` Daniel P. Smith
2024-11-23 18:20 ` [PATCH 07/15] x86/hyperlaunch: initial support for hyperlaunch device tree Daniel P. Smith
2024-11-25 20:11 ` Jason Andryuk
2024-12-11 12:49 ` Daniel P. Smith
2024-12-02 11:37 ` Jan Beulich
2024-12-11 12:55 ` Daniel P. Smith
2024-11-23 18:20 ` [PATCH 08/15] x86/hyperlaunch: locate dom0 kernel with hyperlaunch Daniel P. Smith
2024-11-25 22:54 ` Jason Andryuk
2024-12-11 14:19 ` Daniel P. Smith
2024-12-02 11:53 ` Jan Beulich [this message]
2024-12-11 15:41 ` Daniel P. Smith
2024-12-12 11:25 ` Jan Beulich
2024-11-23 18:20 ` [PATCH 09/15] x86/hyperlaunch: obtain cmdline from device tree Daniel P. Smith
2024-11-25 23:12 ` Jason Andryuk
2024-12-11 15:46 ` Daniel P. Smith
2024-11-23 18:20 ` [PATCH 10/15] x86/hyperlaunch: locate dom0 initrd with hyperlaunch Daniel P. Smith
2024-11-25 23:34 ` Jason Andryuk
2024-12-11 15:49 ` Daniel P. Smith
2024-11-23 18:20 ` [PATCH 11/15] x86/hyperlaunch: add domain id parsing to domain config Daniel P. Smith
2024-11-25 23:45 ` Jason Andryuk
2024-12-02 12:00 ` Jan Beulich
2024-12-11 16:07 ` Daniel P. Smith
2024-12-11 16:06 ` Daniel P. Smith
2024-12-02 12:02 ` Jan Beulich
2024-12-11 16:21 ` Daniel P. Smith
2024-12-19 16:40 ` Daniel P. Smith
2024-11-23 18:20 ` [PATCH 12/15] x86/hyperlaunch: specify dom0 mode with device tree Daniel P. Smith
2024-11-25 23:52 ` Jason Andryuk
2024-12-11 16:24 ` Daniel P. Smith
2024-12-02 12:05 ` Jan Beulich
2024-12-11 16:31 ` Daniel P. Smith
2024-12-02 12:06 ` Jan Beulich
2024-12-11 17:48 ` Daniel P. Smith
2024-12-12 11:31 ` Jan Beulich
2024-11-23 18:20 ` [PATCH 13/15] x86/hyperlaunch: add memory parsing to domain config Daniel P. Smith
2024-11-26 0:03 ` Jason Andryuk
2024-12-11 17:59 ` Daniel P. Smith
2024-12-26 16:16 ` Daniel P. Smith
2024-12-02 12:14 ` Jan Beulich
2024-12-11 18:02 ` Daniel P. Smith
2024-12-12 11:34 ` Jan Beulich
2024-11-23 18:20 ` [PATCH 14/15] x86/hyperlaunch: add max vcpu parsing of hyperlaunch device tree Daniel P. Smith
2024-11-26 0:05 ` Jason Andryuk
2024-12-11 18:05 ` Daniel P. Smith
2024-12-02 12:19 ` Jan Beulich
2024-12-11 19:49 ` Daniel P. Smith
2024-12-12 11:37 ` Jan Beulich
2024-11-23 18:20 ` [PATCH 15/15] x86/hyperlaunch: add capabilities to boot domain Daniel P. Smith
2024-11-26 0:09 ` Jason Andryuk
2024-12-11 19:51 ` Daniel P. Smith
2024-12-02 12:23 ` Jan Beulich
2024-12-11 19:56 ` Daniel P. Smith
2024-12-12 11:40 ` Jan Beulich
2024-11-26 0:11 ` [PATCH 00/15] Hyperlaunch device tree for dom0 Jason Andryuk
2024-12-11 19:57 ` Daniel P. Smith
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=91e6d4e7-b4ff-4e13-8814-95eaac891cf4@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=christopher.w.clark@gmail.com \
--cc=dpsmith@apertussolutions.com \
--cc=jason.andryuk@amd.com \
--cc=roger.pau@citrix.com \
--cc=stefano.stabellini@amd.com \
--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.