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

RE: [PATCH v4 09/17] xen/arm: introduce a helper to parse device tree NUMA distance map


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Henry Wang <Henry.Wang@xxxxxxx>
  • Date: Wed, 26 Apr 2023 07:36:15 +0000
  • Accept-language: zh-CN, 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=JGaej4NQ+uswKUQdRV/BuZd/DUx0sCqy/7Xx/koFV/Y=; b=PF2bNFS9ck3ji2QedmH95lbkDyb+Di8FNHtVn28myAMMm0S5sFj2JTbiRtlscWytbu1kCRMdAHKpNszuxC/9RPjfs1FG6xS+2+UMacg5T7xj7CLVURmsn7lkLwXp2sV0rZL9VubFDEz1DrXTPew1Buetgqv2i3IWjS5RyvVMQLutOispjK8GQN2UO7rS8BlpE9Bp0KHfRbCVqeusW/DaeZFMQhQYmmGMNxwI6P8UTIjqyK3y1kV3fXafpUq8bFD/jsdqquB26sHpnYs0T3sdgptEGcbW9/H1Njgs54nMQCzowE4/0/qwuMlgJ9lBFSS+hklrdvqM8TkT1Zw5e1vWvQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B0qpccbsyImua9+2a7u2zfDoorXpKTcXLlrW1Do6NX1XVGA3NA75smXoTjCaEIYdcXwaEtvH6QUYP16/mJkLCDdPM+7Uw1Q4UIqUoKeSfTmONddF6mvgwCGl4ttbllfJVWs6ioYP8ihWt/zmnbZc4Eh31zpCZhbCcuxkntNmqxhrOx6bNLqxDGMeGZsd73Txn6wyQtwIsGq26UZOO7+EIzCgrFRSLpzfawcDTE/F4B/bsz3cv8Hf/mQbUVViOTfqu+zN+camLAiXuFjT+YbYdhO6NQbO3b2J+N8guObibNBKj2gl5bX7PSw8X/506R/5+1SpkGj0VJjxV72509X38A==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Wei Chen <Wei.Chen@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 26 Apr 2023 07:36:54 +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: AQHZd0ulMpqFICe/LUiDVq6+aDsW9687tFqAgAFSIKCAACZ1gIAABguQ
  • Thread-topic: [PATCH v4 09/17] xen/arm: introduce a helper to parse device tree NUMA distance map

Hi Jan,

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Subject: Re: [PATCH v4 09/17] xen/arm: introduce a helper to parse device
> tree NUMA distance map
> 
> On 26.04.2023 08:29, Henry Wang wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@xxxxxxxx>
> >>
> >>> +        distance = dt_next_cell(1, &matrix);
> >>
> >> Upon second thought I checked what dt_next_cell() returns: You're silently
> >> truncating here and then ...
> >>
> >>> +            /* Bi-directions are not set, set both */
> >>> +            numa_set_distance(from, to, distance);
> >>> +            numa_set_distance(to, from, distance);
> >>
> >> ... here again. Is that really the intention?
> >
> > By hunting down the historical discussions I found that using dt_next_cell()
> is
> > what Julien suggested 2 years ago in the RFC series [1]. Given the 
> > truncation
> > here is for node id (from/to) and distance which I am pretty sure will not
> > exceed 32-bit range, I think the silent truncation is safe.
> 
> That discussion is orthogonal; the previously used dt_read_number() is no
> different in the regard I'm referring to.
> 
> > However I understand your point here, the silent truncation is not ideal, so
> > I wonder if you have any suggestions to improve, do you think I should
> change
> > these variables to u64 or maybe I need to do the explicit type cast or any
> > better suggestions from you? Thanks!
> 
> So one thing I overlooked is that by passing 1 as the first argument, you
> only request a 32-bit value. Hence there's no (silent) truncation then on
> the dt_next_cell() uses. But the numa_set_distance() calls still truncate
> to 8 bits. Adding explicit type casts won't help at all - truncation will
> remain as silent as it was before. However, numa_set_distance()'s first
> two arguments could easily become "unsigned int", resulting in its node
> related bounds checking to take care of all truncation issues. The
> "distance" parameter already is unsigned int, and is already being bounds
> checked against NUMA_NO_DISTANCE.

Great points! Thanks for pointing the 8-bit truncation out. You are correct.
Somehow my impression of numa_set_distance()'s first two arguments are
already "unsigned int" so I missed this part...Sorry.

In that case, I think I will add a check between "from, to" and MAX_NUMNODES
as soon as the values of "from" and "to" are populated by dt_next_cell().
Hopefully this will address your concern.

Kind regards,
Henry

> 
> Jan
> 
> > [1] https://lists.xenproject.org/archives/html/xen-devel/2021-
> 08/msg01175.html
> >
> > Kind regards,
> > Henry


 


Rackspace

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