[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 10/16] x86/hyperlaunch: obtain cmdline from device tree


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Alejandro Vallejo <agarciav@xxxxxxx>
  • Date: Mon, 14 Apr 2025 15:23:25 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Pp9xxz8ykLGzTW+jm5pxYvxvYog1N8ZMeDHRKQyyLHM=; b=X6rD1mtmkS6LguWvSO2dV1HDs1avans1F36O+gnOFR5GGU8hv9Y345fPHkbO+EdqOUYUnLm3ZcHtRnQLfeus9O3oLnjMicbYLFLaFy0rMQHP2//ZlgBYYDeQ0DlNtTZcr+w4RUIRqhEyftsnLveU578G20Yw9CqX8sUpTm/6fqMisHK7vEU/tr61Q94J2hWglWcMo19d/EHemW3KmBZv9RB1zzVLlM7BtdAxnz/32J4HE5azVVgyfAkGqQ6ERMR8Ujs90NZHHyndY4HJmlIk0OYC+R64owiyTkHxes+FAB8aRyxofnwrsnuDGxyx/zLMN061gYtfgcwOuEzF1lQQ/Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jDi9yO2iI5QXGXwlxFWQB/lQlskYgJ2sUOAFgcvsrcLNTnQTOpCSknQ30fqNfcogsSwslUuKOscTRU2D2wb1xU5YJf7pq3604TA5kSWZ1o5psxVJzplbr4u9Qq1lyXK7yBKRTTb1XWSUZ5ZwaZETJuHggHbM7koeptlSMTic4SJeLaraXf6S7LpULxNntLQTkaHZSkQfSgs94cdxu4u4JIk++YpcYHqWzXwreqb/huXE7fHut6SjJ8g3WnmZFJ8vRVfwEJKMkVSnLXs3+mZSy9hsRoe7rhWo+1U3apZPKnQiXq2+mtufz69SPvZVwIiKURNRFpuU+cE98X/nsfTIbw==
  • Cc: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, Jason Andryuk <jason.andryuk@xxxxxxx>, Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>, "Stefano Stabellini" <sstabellini@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 14 Apr 2025 14:23:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu Apr 10, 2025 at 12:12 PM BST, Jan Beulich wrote:
> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>> --- a/xen/arch/x86/domain-builder/core.c
>> +++ b/xen/arch/x86/domain-builder/core.c
>> @@ -8,9 +8,37 @@
>>  #include <xen/lib.h>
>>  
>>  #include <asm/bootinfo.h>
>> +#include <asm/setup.h>
>>  
>>  #include "fdt.h"
>>  
>> +size_t __init builder_get_cmdline_size(struct boot_info *bi, int offset)
>> +{
>> +#ifdef CONFIG_DOMAIN_BUILDER
>> +    const void *fdt = bootstrap_map_bm(&bi->mods[HYPERLAUNCH_MODULE_IDX]);
>> +    int size = fdt_cmdline_prop_size(fdt, offset);
>> +
>> +    bootstrap_unmap();
>> +    return size < 0 ? 0 : size;
>
> Use max() instead of open-coding it?

Sure. On an unrelated matter, I've also removed the ifdef and relied on
DCE for v4 for this and the next helper.

>
>> --- a/xen/arch/x86/domain-builder/fdt.c
>> +++ b/xen/arch/x86/domain-builder/fdt.c
>> @@ -189,6 +189,12 @@ static int __init process_domain_node(
>>              printk("  kernel: boot module %d\n", idx);
>>              bi->mods[idx].type = BOOTMOD_KERNEL;
>>              bd->kernel = &bi->mods[idx];
>> +
>> +            /* If bootloader didn't set cmdline, see if FDT provides one. */
>> +            if ( bd->kernel->cmdline_pa &&
>> +                 !((char *)__va(bd->kernel->cmdline_pa))[0] )
>> +                bd->kernel->fdt_cmdline = fdt_get_prop_offset(
>> +                    fdt, node, "bootargs", &bd->kernel->cmdline_pa);
>
> Somewhat orthogonal question: Should there perhaps be a way for the boot 
> loader
> provided cmdline to go at the tail of the DT provided one?

That would preclude the bootloader fully overriding what's on the DT.
One can always just copy the cmdline in the DT to the bootloader and
adjust whatever is necessary there for testing. Adding append behaviour
sounds more like a hindrance rather than helpful. To me at least.

>
>> --- a/xen/arch/x86/domain-builder/fdt.h
>> +++ b/xen/arch/x86/domain-builder/fdt.h
>> @@ -12,6 +12,31 @@ struct boot_info;
>>  #define HYPERLAUNCH_MODULE_IDX 0
>>  
>>  #ifdef CONFIG_DOMAIN_BUILDER
>> +
>> +static inline int __init fdt_cmdline_prop_size(const void *fdt, int offset)
>> +{
>> +    int ret;
>> +
>> +    fdt_get_property_by_offset(fdt, offset, &ret);
>> +
>> +    return ret;
>> +}
>> +
>> +static inline int __init fdt_cmdline_prop_copy(
>> +    const void *fdt, int offset, char *cmdline, size_t size)
>> +{
>> +    int ret;
>> +    const struct fdt_property *prop =
>> +        fdt_get_property_by_offset(fdt, offset, &ret);
>> +
>> +    if ( ret < 0 )
>> +        return ret;
>> +
>> +    ASSERT(size > ret);
>> +
>> +    return strlcpy(cmdline, prop->data, ret);
>> +}
>
> What's the rationale for these to be separate functions, rather then the code
> being integrated into their sole callers? Especially for the former the extra
> layer feels excessive.

I've moved them onto domain-builder/fdt.c (where I believe they were
originally?) for v4.

>
>> --- a/xen/arch/x86/include/asm/domain-builder.h
>> +++ b/xen/arch/x86/include/asm/domain-builder.h
>> @@ -3,6 +3,10 @@
>>  
>>  struct boot_info;
>>  
>> +size_t __init builder_get_cmdline_size(struct boot_info *bi, int offset);
>> +int __init builder_get_cmdline(
>> +    struct boot_info *bi, int offset, char *cmdline, size_t size);
>
> No __init on declarations please.

Ack.

>
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -984,7 +984,10 @@ static size_t __init domain_cmdline_size(
>>  {
>>      size_t s = bi->kextra ? strlen(bi->kextra) : 0;
>>  
>> -    s += bd->kernel->cmdline_pa ? strlen(__va(bd->kernel->cmdline_pa)) : 0;
>> +    if ( bd->kernel->fdt_cmdline )
>> +        s += builder_get_cmdline_size(bi, bd->kernel->cmdline_pa);
>> +    else
>> +        s += strlen(__va(bd->kernel->cmdline_pa));
>
> Why's the check lost for bd->kernel->cmdline_pa being non-zero?

Shouldn't have been, indeed.
>
>> @@ -1047,9 +1050,12 @@ static struct domain *__init create_dom0(struct 
>> boot_info *bi)
>>          if ( !(cmdline = xzalloc_array(char, cmdline_size)) )
>>              panic("Error allocating cmdline buffer for %pd\n", d);
>>  
>> -        if ( bd->kernel->cmdline_pa )
>> +        if ( bd->kernel->fdt_cmdline )
>> +            builder_get_cmdline(
>> +                bi, bd->kernel->cmdline_pa, cmdline, cmdline_size);
>> +        else
>
> Same here.

Ack.

>
>>              strlcpy(cmdline,
>> -                    cmdline_cook(__va(bd->kernel->cmdline_pa), bi->loader),
>> +                    cmdline_cook(__va(bd->kernel->cmdline_pa),bi->loader),
>
> The change to this line is bogus altogether.

Ugh, yes.

>
>> --- a/xen/include/xen/libfdt/libfdt-xen.h
>> +++ b/xen/include/xen/libfdt/libfdt-xen.h
>> @@ -23,6 +23,29 @@ static inline uint64_t  __init fdt_cell_as_u64(const 
>> fdt32_t *cell)
>>      return ((uint64_t)fdt32_to_cpu(cell[0]) << 32) | fdt32_to_cpu(cell[1]);
>>  }
>>  
>> +static inline bool __init fdt_get_prop_offset(
>> +    const void *fdt, int node, const char *name, unsigned long *offset)
>> +{
>> +    int ret, poffset;
>> +    const char *pname;
>> +
>> +    fdt_for_each_property_offset(poffset, fdt, node)
>> +    {
>> +        fdt_getprop_by_offset(fdt, poffset, &pname, &ret);
>> +
>> +        if ( ret < 0 )
>> +            continue;
>> +
>> +        if ( strcmp(pname, name) == 0 )
>> +        {
>> +            *offset = poffset;
>
> Variable naming looks backwards here.
>
> Jan

I think the leading p stands for "property" (for the sake of giving it a
name). But I see how that might be confusing when interpreted with a
Hungarian notation lens.

I'll invert it. It doesn't matter which is which, after all.

Cheers,
Alejandro



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.