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

Re: [PATCH v2 05/10] xen/x86: Use ASSERT instead of VIRTUAL_BUG_ON for phys_to_nid


  • To: Wei Chen <Wei.Chen@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 26 Apr 2022 16:42:21 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=KvWIhYE4cEBXVy3Ooxi1iGKA9YQ/B58YM7J25bpT9dM=; b=J6cyBWi3cpWGWX2T80cQ8UG3ynMUNkusmCpBq5mRbm7cao9yO7RAl8IatE6RHMXjQ0rtLCZr6ijh6Jq6qga6W1eirGL/VVTrF8+fqIjRvUNsk+H1UP1AlHB3zSRaoqCdXzqN9nIXAexBndtsOzLn/ko3BlEhSpA4Cp2w6oM2N+ZbNCLT5MB9EQf0I8FhTHdA4XpHOtlnoN5vnYua/p13OwXb6RdzQfV3eGYEkIm3tHL8Mfj9nNvMDFCUy84JcSGPTgUJSwqhZHqwUxAe4yl4cG6b2den5I2fYQyCBhbhULJgSGl6Wh1r+4YZEwSJQIFfU8pYmASHUd37DKJEmbqlDA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dBoIHk7C1/Y+zbV21qYEFcEwJqWPZqKYI5gvnVc/lwpoXVqvZsKxV1AHWcXudRzBKMgMBsfIIaHHCbFLIAZbgOKei1miejZWZBeE7KyWluANYvgxzwllJcn3017jcIgEeifpJ+QZnn++GGn8XnuiWYUMuZGt5P3Fe9IZFMv7zdTw9T9dWocrW2AA2gOzPrbeCe7jJwlfAMpuCajcL7EzsDtWfuPwZ/H96q70rJQtiicK3ODG0YWn7XwmLzvPmYdEToKWkRhSyZGJ8CdAxfx9MjU6ksEThO1Ucjaog1PMSY+QjdBBdhW0roH3IK4yLAFGWnMTkWbg3Fy7kEzwMwaazA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: nd@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 26 Apr 2022 14:42:34 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 26.04.2022 12:59, Wei Chen wrote:
> On 2022/4/26 17:02, Jan Beulich wrote:
>> On 18.04.2022 11:07, Wei Chen wrote:
>>> VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
>>> results in two lines of error-checking code in phys_to_nid
>>> that is not actually working and causing two compilation
>>> errors:
>>> 1. error: "MAX_NUMNODES" undeclared (first use in this function).
>>>     This is because in the common header file, "MAX_NUMNODES" is
>>>     defined after the common header file includes the ARCH header
>>>     file, where phys_to_nid has attempted to use "MAX_NUMNODES".
>>>     This error was resolved when we moved the definition of
>>>     "MAX_NUMNODES" to x86 ARCH header file. And we reserve the
>>>     "MAX_NUMNODES" definition in common header file through a
>>>     conditional compilation for some architectures that don't
>>>     need to define "MAX_NUMNODES" in their ARCH header files.
>>
>> No, that's setting up a trap for someone else to fall into, especially
>> with the #ifdef around the original definition. Afaict all you need to
>> do is to move that #define ahead of the #include in xen/numa.h. Unlike
>> functions, #define-s can reference not-yet-defined identifiers.
>>
> 
> I had tried it before. MAX_NUMNODES depends on NODE_SHIFT. But
> NODE_SHIFT depends on the definition status in asm/numa.h. If I move 
> MAX_NUMNODES to before asm/numa.h, then I have to move NODES_SHIFT as 
> well. But this will break the original design. NODES_SHIFT in xen/numa.h 
> will always be defined before asm/numa.h. This will be a duplicated 
> definition error.

I'm afraid I don't follow. MAX_NUMNODES depends on NODES_SHIFT only as
soon as some code actually uses MAX_NUMNODES. It does not require
NODES_SHIFT to be defined up front. Of course with the current layout
(phys_to_nid() living in an inline function in asm/numa.h) things won't
build. But wasn't the plan to move phys_to_nid() to xen/numa.h as well?

Otherwise I'd recommend to introduce a new header, say numa-defs.h,
holding (for now) just NODES_SHIFT. Then you'd include asm/numa-defs.h
first and asm/numa.h only after having defined MAX_NUMNODES. But
splitting the header should only be a last resort if things can't be
made work another way.

> How about I move MAX_NUMNODES to arm and x86 asm/numa.h in this patch
> at the same time? Because in one of following patches, MAX_NUMNODES and
> phys_to_nid will be moved to xen/numa.h at the same time?
> 
>>> 2. error: wrong type argument to unary exclamation mark.
>>>     This is because, the error-checking code contains !node_data[nid].
>>>     But node_data is a data structure variable, it's not a pointer.
>>>
>>> So, in this patch, we use ASSERT instead of VIRTUAL_BUG_ON to
>>> enable the two lines of error-checking code. And fix the left
>>> compilation errors by replacing !node_data[nid] to
>>> !node_data[nid].node_spanned_pages.
>>>
>>> Because when node_spanned_pages is 0, this node has no memory,
>>> numa_scan_node will print warning message for such kind of nodes:
>>> "Firmware Bug or mis-configured hardware?".
>>
>> This warning is bogus - nodes can have only processors. Therefore I'd
>> like to ask that you don't use it for justification. And indeed you
> 
> Yes, you're right, node can only has CPUs! I will remove it.
> 
>> don't need to: phys_to_nid() is about translating an address. The
>> input address can't be valid if it maps to a node with no memory.
>>
> 
> Can I understand your comment:
> Any input address is invalid, when node_spanned_pages is zero, because
> this node has no memory?

It's getting close, but it's not exactly equivalent I think. A node
with 0 bytes of memory might (at least in theory) have an entry in
memnodemap[]. But finding a node ID for that address would still
not mean that at least one byte of memory at that address is present
on the given node, because the node covers 0 bytes.

Jan




 


Rackspace

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