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

Re: [PATCH v3 14/16] x86/hyperlaunch: add memory parsing to domain config


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Alejandro Vallejo <agarciav@xxxxxxx>
  • Date: Mon, 14 Apr 2025 19:59:19 +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=U+kUEEgJlwdl3Tb1dK+FcrO+rHmP2LGO2wJVEO9Kz6M=; b=Pc7MJ16IWUzrpiWha1F319n56+NKyvL3UcwmE6U3oumdqZDPbvG6947rYbRFbE+KXu4VNfb0/dLx33ZLRGsUl3SJ4v3fh6bZcpdpCYJo9gLXLCxpiEYdPIqbB7MVGJoAKYP2TA+dKes4A/7ReppQVrvhHfF9M09FwexYKGzGrOWjF2POcmezamxk5AaXyFk9Xohx6S44LW6vngRdsyQBeraZENIkHpPX1A14TS/oJaDwNzPchrixo5XClOx+W/vMRgky/iStdmfN78preY5rPW4Cmsov5B9KowVkolmmscuOZpYQ9HK4AZy1x1kOIGQ/4DNtZzVDLwNcC2noG8dNRA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=k3UjrMk17lg7t/iCzv1jWTPrNIew/KHnf2Y87fjq5hFyOEEoMIp1qn3kWtERM0CTQ/kK12uLmuY4Xxlrp0aaig/QlEruEuU3Do2I1vQ0justvY00evZKlDNVL+oyGVPIk7wcycicTGbIsRzzBbTV3ngNSJiqXEaWezKJpiQZ9yOvSgzIW1IMGfCa9c2AInLq/jiWUAb5yjBQzz21K1nBUNgGamNuANWJ3bHmv0XGjO2teQVxIbgUkcOH6Ew156oz6Pd+w48SxQWlXoRUoUCYq4aKGE//Dw5gSE3cBQHvhpmNI2pKumDuIVfI57s4uhkaDrBZAwfCN/G299RnZaZXWg==
  • 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 18:59:37 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu Apr 10, 2025 at 1:03 PM BST, Jan Beulich wrote:
> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>> @@ -212,6 +213,39 @@ static int __init process_domain_node(
>>              else
>>                  printk("PV\n");
>>          }
>> +        else if ( strncmp(prop_name, "memory", name_len) == 0 )
>> +        {
>> +            uint64_t kb;
>> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
>
> Nit (you know what I have to say here, and again below.)

Ack

>
>> +            {
>> +                printk("  failed processing memory for domain %s\n", name);
>> +                return -EINVAL;
>
> Any reason to override fdt_prop_as_u64()'s return value here?

Mostly to avoid needing to recover the error code. I'll just do it.

>
>> +            }
>> +            bd->mem_pages = PFN_DOWN(kb * SZ_1K);
>> +            printk("  memory: %ld kb\n", kb);
>> +        }
>> +        else if ( strncmp(prop_name, "mem-min", name_len) == 0 )
>> +        {
>> +            uint64_t kb;
>> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
>> +            {
>> +                printk("  failed processing memory for domain %s\n", name);
>> +                return -EINVAL;
>> +            }
>> +            bd->min_pages = PFN_DOWN(kb * SZ_1K);
>> +            printk("  min memory: %ld kb\n", kb);
>> +        }
>> +        else if ( strncmp(prop_name, "mem-max", name_len) == 0 )
>> +        {
>> +            uint64_t kb;
>> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
>> +            {
>> +                printk("  failed processing memory for domain %s\n", name);
>
> All three error messages being identical doesn't help diagnosing issues.

Indeed. Will add the prop that trigger each.

>
>> --- a/xen/include/xen/libfdt/libfdt-xen.h
>> +++ b/xen/include/xen/libfdt/libfdt-xen.h
>> @@ -34,6 +34,16 @@ static inline int __init fdt_prop_as_u32(
>>      return 0;
>>  }
>>  
>> +static inline int __init fdt_prop_as_u64(
>> +    const struct fdt_property *prop, uint64_t *val)
>> +{
>> +    if ( !prop || fdt32_to_cpu(prop->len) < sizeof(u64) )
>> +        return -EINVAL;
>> +
>> +    *val = fdt_cell_as_u64((fdt32_t *)prop->data);
>
> Please avoid casting away const. Looks like I overlooked this in
> fdt_prop_as_u32() that was introduced by an earlier patch.

As part of v4 I moved this and fdt_prop_as_u32() earlier to patch8 and
already adjusted accordingly.

Cheers,
Alejandro



 


Rackspace

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