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

Re: [PATCH v2 10/15] x86/hyperlaunch: locate dom0 initrd with hyperlaunch


  • To: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 30 Jan 2025 17:39:48 +0100
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • 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: Thu, 30 Jan 2025 16:39:58 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 26.12.2024 17:57, Daniel P. Smith wrote:
> Look for a subnode of type `multiboot,ramdisk` within a domain node. If
> found, process the reg property for the MB1 module index.

Unlike for cmdline it doesn't look to be mix-and-match here.

> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -119,6 +119,32 @@ static int __init process_domain_node(
>                  if ( ret > 0 )
>                      bd->kernel->fdt_cmdline = true;
>              }
> +
> +            continue;
> +        }
> +        else if (
> +            fdt_node_check_compatible(fdt, node, "multiboot,ramdisk") == 0 )

I'm sorry, but this isn't style we use. Perhaps

        else if ( fdt_node_check_compatible(
                      fdt, node, "multiboot,ramdisk") == 0 )

if you dislike

        else if ( fdt_node_check_compatible(fdt, node,
                                            "multiboot,ramdisk") == 0 )

> +        {
> +            int idx = dom0less_module_node(fdt, node, size_size, 
> address_size);
> +            if ( idx < 0 )

Nit: Blank line between declaration(s) and statement(s) please. (Again
at least once elsewhere in this patch.)

> +            {
> +                printk("  failed processing ramdisk module for domain %s\n",
> +                       name);
> +                return -EINVAL;
> +            }
> +
> +            if ( idx > bi->nr_modules )
> +            {
> +                printk("  invalid ramdisk module index for domain node 
> (%d)\n",
> +                       bi->nr_domains);
> +                return -EINVAL;
> +            }

See comments on similar printk()s in an earlier patch.

> @@ -2141,22 +2141,25 @@ void asmlinkage __init noreturn __start_xen(void)
>             cpu_has_nx ? XENLOG_INFO : XENLOG_WARNING "Warning: ",
>             cpu_has_nx ? "" : "not ");
>  
> -    /*
> -     * At this point all capabilities that consume boot modules should have
> -     * claimed their boot modules. Find the first unclaimed boot module and
> -     * claim it as the initrd ramdisk. Do a second search to see if there are
> -     * any remaining unclaimed boot modules, and report them as unusued 
> initrd
> -     * candidates.
> -     */
> -    initrdidx = first_boot_module_index(bi, BOOTMOD_UNKNOWN);
> -    if ( initrdidx < MAX_NR_BOOTMODS )
> +    if ( !bi->hyperlaunch_enabled )

Can't this be "if ( !bi->hyperlaunch_enabled && initrdidx < MAX_NR_BOOTMODS )"
and then all of the churn here can be avoided? An unnecessary call to
first_boot_module_index() is unlikely to be the end of the world. Otherwise ...

>      {
> -        bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
> -        bi->domains[0].ramdisk = &bi->mods[initrdidx];
> -        if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < MAX_NR_BOOTMODS )
> -            printk(XENLOG_WARNING
> -                   "Multiple initrd candidates, picking module #%u\n",
> -                   initrdidx);
> +        /*
> +         * At this point all capabilities that consume boot modules should 
> have
> +         * claimed their boot modules. Find the first unclaimed boot module 
> and
> +         * claim it as the initrd ramdisk. Do a second search to see if 
> there are
> +         * any remaining unclaimed boot modules, and report them as unusued 
> initrd
> +         * candidates.
> +         */
> +        unsigned int initrdidx = first_boot_module_index(bi, 
> BOOTMOD_UNKNOWN);
> +        if ( initrdidx < MAX_NR_BOOTMODS )
> +        {
> +            bi->mods[initrdidx].type = BOOTMOD_RAMDISK;
> +            bi->domains[0].ramdisk = &bi->mods[initrdidx];
> +            if ( first_boot_module_index(bi, BOOTMOD_UNKNOWN) < 
> MAX_NR_BOOTMODS )
> +                printk(XENLOG_WARNING
> +                       "Multiple initrd candidates, picking module #%u\n",
> +                       initrdidx);
> +        }

... please pay attention to line length when re-indenting. (If you still need
to re-indent, perhaps also s/unusued/unused/ in the comment, while you touch
it.)

Jan



 


Rackspace

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