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

RE: [PATCH 07/37] xen/x86: use paddr_t for addresses in NUMA node structure


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Wei Chen <Wei.Chen@xxxxxxx>
  • Date: Wed, 19 Jan 2022 06:33:58 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=axrDoozhRsWwFXPY+RsC9c2DcNVIDRbpT9/kt++voIM=; b=nlVy+fBn+GH98E372dlzan/jmsk36CcI0G5SbmCr7D9qqhOSMgFYTfPvGeTemWO461wExdCX1xghxo9rAbUke+L3GBjlH57ZojUHlfKe90Z5bTQWm2F38r74PfktAg2XW4MXwuhPQv7AAYX/q/hk9JRuMS82B9WmNdw42PELgVfTXJeE9vqD5+jrYSEV4oS6bCN1Y9xMos4kDkqBmr1gcFJrKUK5+57iicmO9ERPWKaMzC8Mump9kDxpLkH4HkHHJk2d1d9hBf1Fk3j88CNx2Cv878r2vTuPFoGIpsbt4aBfgccuJ/0QzUvccrIGuqzj/g+dWf3zFPx4JXnWgz50sg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SIccQifoY6xYbE1Wv7non/RGhXxkdKCptTVE8fJzrczMnrq4+em3p7Q2K5YRYCvxWIIiTHIWoSqtRPdf5m45WL+lq9vhDId6JslZaDJ/WEoCnLxO1mzFQX0vxSZHUyJrzSaHuDP04i6tqFenfddqJ8bLi6yv/llRxeC1UktvSQ0dplXLRfh2ybGeAzZWgXnhrCs1V5zLCp1a4Y/qbeFtGwgzSlvNu17QzJI2x3N8uGG3/qyjqsbweKhAUxirWzWEFGP37MgMODmh67EV7pATSegq57bN/XFLm+EJZIK3i95W0pt5cbqhvqLGPF/qLicjNcS63TZPiZgqBrYjsP5CJg==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, "julien@xxxxxxx" <julien@xxxxxxx>
  • Delivery-date: Wed, 19 Jan 2022 06:34:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHXsHMRNGZeupZbtEeYycYXK8HrbKxpnZqAgAD0aqA=
  • Thread-topic: [PATCH 07/37] xen/x86: use paddr_t for addresses in NUMA node structure

Hi Jan,

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 2022年1月18日 23:23
> To: Wei Chen <Wei.Chen@xxxxxxx>
> Cc: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx; sstabellini@xxxxxxxxxx; julien@xxxxxxx
> Subject: Re: [PATCH 07/37] xen/x86: use paddr_t for addresses in NUMA node
> structure
> 
> On 23.09.2021 14:02, Wei Chen wrote:
> > @@ -201,11 +201,12 @@ void __init numa_init_array(void)
> >  static int numa_fake __initdata = 0;
> >
> >  /* Numa emulation */
> > -static int __init numa_emulation(u64 start_pfn, u64 end_pfn)
> > +static int __init numa_emulation(unsigned long start_pfn,
> > +                                 unsigned long end_pfn)
> >  {
> >      int i;
> >      struct node nodes[MAX_NUMNODES];
> > -    u64 sz = ((end_pfn - start_pfn)<<PAGE_SHIFT) / numa_fake;
> > +    u64 sz = pfn_to_paddr(end_pfn - start_pfn) / numa_fake;
> 
> Nit: Please convert to uint64_t (and alike) whenever you touch a line
> anyway that uses being-phased-out types.
> 

Ok, I will do it.

> > @@ -249,24 +250,26 @@ static int __init numa_emulation(u64 start_pfn,
> u64 end_pfn)
> >  void __init numa_initmem_init(unsigned long start_pfn, unsigned long
> end_pfn)
> >  {
> >      int i;
> > +    paddr_t start, end;
> >
> >  #ifdef CONFIG_NUMA_EMU
> >      if ( numa_fake && !numa_emulation(start_pfn, end_pfn) )
> >          return;
> >  #endif
> >
> > +    start = pfn_to_paddr(start_pfn);
> > +    end = pfn_to_paddr(end_pfn);
> 
> Nit: Would be slightly neater if these were the initializers of the
> variables.

But if this function returns in numa_fake && !numa_emulation,
will the two pfn_to_paddr operations be waste?

> 
> >  #ifdef CONFIG_ACPI_NUMA
> > -    if ( !numa_off && !acpi_scan_nodes((u64)start_pfn << PAGE_SHIFT,
> > -         (u64)end_pfn << PAGE_SHIFT) )
> > +    if ( !numa_off && !acpi_scan_nodes(start, end) )
> >          return;
> >  #endif
> >
> >      printk(KERN_INFO "%s\n",
> >             numa_off ? "NUMA turned off" : "No NUMA configuration
> found");
> >
> > -    printk(KERN_INFO "Faking a node at %016"PRIx64"-%016"PRIx64"\n",
> > -           (u64)start_pfn << PAGE_SHIFT,
> > -           (u64)end_pfn << PAGE_SHIFT);
> > +    printk(KERN_INFO "Faking a node at %016"PRIpaddr"-%016"PRIpaddr"\n",
> > +           start, end);
> 
> When switching to PRIpaddr I suppose you did look up what that one
> expands to? IOW - please drop the 016 from here.

Oh, yes, I forgot to drop the duplicated 016. I would do it.

> 
> > @@ -441,7 +441,7 @@ void __init srat_parse_regions(u64 addr)
> >         acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat))
> >             return;
> >
> > -   srat_region_mask = pdx_init_mask(addr);
> > +   srat_region_mask = pdx_init_mask((u64)addr);
> 
> I don't see the need for a cast here.
> 

current addr type has been changed to paddr_t, but pdx_init_mask
accept parameter type is u64. I know paddr_t is a typedef of
u64 on Arm64/32, or unsinged long on x86. In current stage,
their machine byte-lengths are the same. But in case of future
changes I think an explicit case here maybe better? 

> > @@ -489,7 +489,7 @@ int __init acpi_scan_nodes(u64 start, u64 end)
> >     /* Finally register nodes */
> >     for_each_node_mask(i, all_nodes_parsed)
> >     {
> > -           u64 size = nodes[i].end - nodes[i].start;
> > +           paddr_t size = nodes[i].end - nodes[i].start;
> >             if ( size == 0 )
> 
> Please take the opportunity and add the missing blank line between
> declarations and statements.
> 

Ok

> > --- a/xen/include/asm-x86/numa.h
> > +++ b/xen/include/asm-x86/numa.h
> > @@ -16,7 +16,7 @@ extern cpumask_t     node_to_cpumask[];
> >  #define node_to_cpumask(node)    (node_to_cpumask[node])
> >
> >  struct node {
> > -   u64 start,end;
> > +   paddr_t start,end;
> 
> Please take the opportunity and add the missing blank after the comma.
> 

Ok

> Jan


 


Rackspace

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