From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EE556221F13 for ; Wed, 7 May 2025 11:55:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746618907; cv=none; b=icc+YNVaZm2jrF0YdhQdOHG6NVYWeqvx64uVoawxR3x9nfOkSh84d5pTNwyhL7eTeRNqm9HdP6+VK2b1HU6tja2TVUuDi4LquNAAXtCiHu8Y77vfIKlsVQx1NpTaZKaNAyLqjCLYRORP1uc8m6iZf7DyJr8k9OYNWV/l2PF3qdc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746618907; c=relaxed/simple; bh=tS3Rw4nlY/7RSa9MTkhDuTA/rbGGwrvkX7fxwDdtNE8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PUDY7n7YDjTvyVkoyI2rOSEMsHV5C5HdsthzSAiIr/ZtLX+53e2IBOsSnHWsEhL88X02aZe+++P9d+r/IXnUn99cPt8555H8sgPrZstoO2uHFbvHeD2JPX3viibI2UBYkhcEPOuCyuAqz8tSEFHfD7BiMiFCHa1OPH1MFLsF1rA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2D5E2339; Wed, 7 May 2025 04:54:55 -0700 (PDT) Received: from bogus (e133711.arm.com [10.1.196.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 566653F5A1; Wed, 7 May 2025 04:55:03 -0700 (PDT) Date: Wed, 7 May 2025 12:55:00 +0100 From: Sudeep Holla To: "Rafael J. Wysocki" Cc: Yicong Yang , lenb@kernel.org, linux-acpi@vger.kernel.org, jmeurin@google.com, jeremy.linton@arm.com, jonathan.cameron@huawei.com, zhanjie9@hisilicon.com, prime.zeng@hisilicon.com, yangyicong@hisilicon.com, linuxarm@huawei.com Subject: Re: [PATCH] ACPI: PPTT: Fix table length check when parsing processor nodes Message-ID: <20250507-obedient-knowing-galago-245e7c@sudeepholla> References: <20250507035124.28071-1-yangyicong@huawei.com> <20250507-devout-mysterious-jackal-e50e00@sudeepholla> <20250507-venomous-feathered-skink-77ea16@sudeepholla> Precedence: bulk X-Mailing-List: linux-acpi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, May 07, 2025 at 01:51:58PM +0200, Rafael J. Wysocki wrote: > On Wed, May 7, 2025 at 1:47 PM Sudeep Holla wrote: > > > > On Wed, May 07, 2025 at 01:44:26PM +0200, Rafael J. Wysocki wrote: > > > On Wed, May 7, 2025 at 1:40 PM Sudeep Holla wrote: > > > > > > > > On Wed, May 07, 2025 at 11:51:24AM +0800, Yicong Yang wrote: > > > > > From: Yicong Yang > > > > > > > > > > Below error is met on my board and QEMU VM on SMT or non-SMT machine: > > > > > ACPI PPTT: PPTT table found, but unable to locate core 31 (31) > > > > > > > > > > This is because the processor node is found by iterating the PPTT > > > > > table under condition (for both acpi_find_processor_node() and > > > > > acpi_pptt_leaf_node()): > > > > > while (entry + proc_sz < table_end) > > > > > [parse the processor node] > > > > > > > > > > If the last processor node is happened to be the last node in the > > > > > PPTT table, above condition will always be false since > > > > > entry + proc_sz == table_end. Thus the last CPU is not parsed. > > > > > Fix the loop condition to resolve the issue. > > > > > > > > > > This issue is exposed by [1] but the root cause is explained above. > > > > > Before [1] entry + proc_sz is always smaller than table_end. > > > > > > > > > > > > > Another thread [1] with similar patch. > > > > > > OK, so is this a correct fix? > > > > While it may fix the issue on the surface, I just want to be sure there > > are no other issues with the PPTT table presented from the firmware. > > I will asked some questions on that thread before I can agree on the solution. > > Yeah, it looks like table_end points to the last byte of the table > instead of pointing to the first byte after the end of the table. Indeed and also we should have private resources like L1 cache described after the initial 20 bytes of the node. So I am bit worried if this will just hide other problems while it may solve this problem by looks of it. This example doesn't look like a proper PPTT matching real systems. -- Regards, Sudeep