From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
xen-devel@lists.xenproject.org
Cc: jason.andryuk@amd.com, christopher.w.clark@gmail.com,
stefano.stabellini@amd.com, "Jan Beulich" <jbeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH v9 1/6] x86/boot: convert domain construction to use boot info
Date: Fri, 15 Nov 2024 09:32:22 -0500 [thread overview]
Message-ID: <13a6a3c8-ff72-4b59-bf48-8fa925cadcbb@apertussolutions.com> (raw)
In-Reply-To: <305651e4-1567-4675-867e-94fc5bf9caf8@citrix.com>
On 11/15/24 09:25, Andrew Cooper wrote:
> On 15/11/2024 1:11 pm, Daniel P. Smith wrote:
>> With all the components used to construct dom0 encapsulated in struct boot_info
>> and struct boot_module, it is no longer necessary to pass all them as
>> parameters down the domain construction call chain. Change the parameter list
>> to pass the struct boot_info instance and the struct domain reference.
>>
>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
>
> There are two minor things needing noting in the commit message.
>
> 1) dom0_construct() turns i from being signed to unsigned. This is
> necessary for it's new use, and compatible with all pre-existing uses.
>
> 2) dom0_construct() also splits some 3-way assignments to placate MISRA,
> on lines which are modified.
Ack.
>> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
>> index 3dd913bdb029..d1bdf1b14601 100644
>> --- a/xen/arch/x86/hvm/dom0_build.c
>> +++ b/xen/arch/x86/hvm/dom0_build.c
>> @@ -642,15 +643,15 @@ static bool __init check_and_adjust_load_address(
>> return true;
>> }
>>
>> -static int __init pvh_load_kernel(struct domain *d, const module_t *image,
>> - unsigned long image_headroom,
>> - module_t *initrd, void *image_base,
>> - const char *cmdline, paddr_t *entry,
>> - paddr_t *start_info_addr)
>> +static int __init pvh_load_kernel(
>> + struct domain *d, struct boot_module *image, struct boot_module *initrd,
>> + paddr_t *entry, paddr_t *start_info_addr)
>> {
>> - void *image_start = image_base + image_headroom;
>> - unsigned long image_len = image->mod_end;
>> - unsigned long initrd_len = initrd ? initrd->mod_end : 0;
>> + void *image_base = bootstrap_map_bm(image);
>> + void *image_start = image_base + image->headroom;
>> + unsigned long image_len = image->mod->mod_end;
>> + unsigned long initrd_len = initrd ? initrd->mod->mod_end : 0;
>> + const char *cmdline = __va(image->cmdline_pa);
>
> This isn't safe. __va(0) != NULL, so later between ...
Yah, that was careless to assume.
>> struct elf_binary elf;
>> struct elf_dom_parms parms;
>> paddr_t last_addr;
>> @@ -725,8 +726,8 @@ static int __init pvh_load_kernel(struct domain *d, const module_t *image,
>
> ... these two hunks in the calculation for last_addr, we have:
>
> ... cmdline ? ROUNDUP(strlen(cmdline) + 1, ...
>
> which does the wrong thing. (And includes the 16bit IVT onto the
> guest's cmdline.)
>
>
> I'd suggest doing the same as we do with initrd_len/etc, and having:
>
> const char *cmdline = image->cmdline_pa ? __va(image->cmdline_pa) :
> NULL;
>
> to maintain the prior semantics.
Agreed.
>>
>> if ( initrd != NULL )
>> {
>> - rc = hvm_copy_to_guest_phys(last_addr, mfn_to_virt(initrd->mod_start),
>> - initrd_len, v);
>> + rc = hvm_copy_to_guest_phys(
>> + last_addr, mfn_to_virt(initrd->mod->mod_start), initrd_len, v);
>
> This is a temporary adjustment, ending up shorter than it starts by
> patch 3. I've tweaked it to reduce the churn overall. I can live with
> 83 chars width for a commit or two...
Just trying to ensure I don't get dinged, so no objection on my part.
>> diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
>> index cc882bee61c3..6be3d7745fab 100644
>> --- a/xen/arch/x86/pv/dom0_build.c
>> +++ b/xen/arch/x86/pv/dom0_build.c
>> @@ -354,13 +355,10 @@ static struct page_info * __init alloc_chunk(struct domain *d,
>> return page;
>> }
>>
>> -static int __init dom0_construct(struct domain *d,
>> - const module_t *image,
>> - unsigned long image_headroom,
>> - module_t *initrd,
>> - const char *cmdline)
>> +static int __init dom0_construct(struct boot_info *bi, struct domain *d)
>> {
>> - int i, rc, order, machine;
>> + unsigned int i;
>> + int rc, order, machine;
>> bool compatible, compat;
>> struct cpu_user_regs *regs;
>> unsigned long pfn, mfn;
>> @@ -374,10 +372,13 @@ static int __init dom0_construct(struct domain *d,
>> unsigned int flush_flags = 0;
>> start_info_t *si;
>> struct vcpu *v = d->vcpu[0];
>> - void *image_base = bootstrap_map(image);
>> - unsigned long image_len = image->mod_end;
>> - void *image_start = image_base + image_headroom;
>> - unsigned long initrd_len = initrd ? initrd->mod_end : 0;
>> + struct boot_module *image;
>> + struct boot_module *initrd = NULL;
>> + void *image_base;
>> + unsigned long image_len;
>> + void *image_start;
>> + unsigned long initrd_len = 0;
>> + const char *cmdline;
>
> I'm tempted to put in some newlines here, just to break up the giant
> block of variables.
Yes, this is a very long block of declarations.
> This use of cmdline in principle needs a similar adjustment to the pvh
> case, but it's only used once, so I suggest this instead:
>
> @@ -984,8 +982,8 @@ static int __init dom0_construct(struct boot_info
> *bi, struct domain *d)
> }
>
> memset(si->cmd_line, 0, sizeof(si->cmd_line));
> - if ( cmdline != NULL )
> - strlcpy((char *)si->cmd_line, cmdline, sizeof(si->cmd_line));
> + if ( image->cmdline_pa )
> + strlcpy((char *)si->cmd_line, __va(image->cmdline_pa),
> sizeof(si->cmd_line));
>
> #ifdef CONFIG_VIDEO
> if ( !pv_shim && fill_console_start_info((void *)(si + 1)) )
>
>
> [edit] Turns out you do this in patch 6 anyway, so this way around will
> reduce churn.
Ack.
> Happy to fix on commit.
No objection.
v/r,
dps
next prev parent reply other threads:[~2024-11-15 14:33 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-15 13:11 [PATCH v9 0/6] Boot modules for Hyperlaunch Daniel P. Smith
2024-11-15 13:11 ` [PATCH v9 1/6] x86/boot: convert domain construction to use boot info Daniel P. Smith
2024-11-15 14:25 ` Andrew Cooper
2024-11-15 14:32 ` Daniel P. Smith [this message]
2024-11-15 16:33 ` Jason Andryuk
2024-11-15 17:01 ` Andrew Cooper
2024-11-15 17:02 ` Jason Andryuk
2024-11-15 13:12 ` [PATCH v9 2/6] x86/boot: introduce module release Daniel P. Smith
2024-11-15 16:50 ` Jason Andryuk
2024-11-15 17:09 ` Andrew Cooper
2024-11-15 17:16 ` Daniel P. Smith
2024-11-15 17:18 ` Jason Andryuk
2024-11-18 16:13 ` Andrew Cooper
2024-11-15 13:12 ` [PATCH v9 3/6] x86/boot: add start and size fields to struct boot_module Daniel P. Smith
2024-11-15 17:31 ` Jason Andryuk
2024-11-15 13:12 ` [PATCH v9 4/6] x86/boot: introduce boot domain Daniel P. Smith
2024-11-27 10:22 ` Jan Beulich
2024-12-04 16:24 ` Daniel P. Smith
2024-11-15 13:12 ` [PATCH v9 5/6] x86/boot: introduce domid field to struct boot_domain Daniel P. Smith
2024-11-15 15:31 ` Daniel P. Smith
2024-11-27 10:32 ` Jan Beulich
2024-12-04 16:45 ` Daniel P. Smith
2024-12-09 8:55 ` Jan Beulich
2024-12-11 0:57 ` Daniel P. Smith
2024-11-15 13:12 ` [PATCH v9 6/6] x86/boot: add cmdline " Daniel P. Smith
2024-11-15 15:12 ` Daniel P. Smith
2024-11-15 16:34 ` Daniel P. Smith
2024-11-15 18:20 ` Jason Andryuk
2024-11-20 17:57 ` Daniel P. Smith
2024-11-20 22:32 ` Jason Andryuk
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=13a6a3c8-ff72-4b59-bf48-8fa925cadcbb@apertussolutions.com \
--to=dpsmith@apertussolutions.com \
--cc=andrew.cooper3@citrix.com \
--cc=christopher.w.clark@gmail.com \
--cc=jason.andryuk@amd.com \
--cc=jbeulich@suse.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.