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 4B356748D for ; Wed, 7 May 2025 15:35:17 +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=1746632122; cv=none; b=i6ZSwTIQiytJ3O9lVZv2hhk1/UrkRl2ukWjHMnlTv4UZINX4JlSKCxhkeA7njs6OfHvPDZcUdNS0SWocJ2ddWsHBdN+lolLmrUu7lCj74y4dNNzhgSUqPTC2zenuC2ZxaZYLt98b7leUYfdesz2xbmUWyG2BYRc4FuBWOv5gccE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746632122; c=relaxed/simple; bh=ySxCuKnG+VU7PXW4i5MC3ZwUovzp1SBfv4mpjbzgKCQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lTt92yz7+cwPObqm7PjUJms/R68Lm90Uzt5wUxqU5DUY8OCzai7T4HYHzNkFYbAgdSnUK1YDGU/OQAlZdPFSLGu+7A+gNKlCdTcEGYAXcyVNVPCmz+A7Pza1Tj2l2Jxk/bP+g1D9HtK08KVabx3lEtVK8Z4ISVISk/MV1Iw4S2k= 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 6FCA7339; Wed, 7 May 2025 08:35:07 -0700 (PDT) Received: from bogus (e133711.arm.com [10.1.196.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 63F333F58B; Wed, 7 May 2025 08:35:15 -0700 (PDT) Date: Wed, 7 May 2025 16:35:12 +0100 From: Sudeep Holla To: Jonathan Cameron Cc: "Rafael J. Wysocki" , Sudeep Holla , Yicong Yang , , , , , , , , , Subject: Re: [PATCH] ACPI: PPTT: Fix table length check when parsing processor nodes Message-ID: <20250507-melodic-helpful-pudu-7ad0f2@sudeepholla> References: <20250507035124.28071-1-yangyicong@huawei.com> <20250507-devout-mysterious-jackal-e50e00@sudeepholla> <20250507-venomous-feathered-skink-77ea16@sudeepholla> <20250507-obedient-knowing-galago-245e7c@sudeepholla> <20250507153550.0000340f@huawei.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20250507153550.0000340f@huawei.com> On Wed, May 07, 2025 at 03:35:50PM +0100, Jonathan Cameron wrote: > On Wed, 7 May 2025 12:55:00 +0100 > Sudeep Holla wrote: > [...] > > > > 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. > > > > Assuming I'm understanding the bug correctly... > > SMT systems will hit this. There will typically be no private resources > for a thread as the L1I/D shared by multiple threads (which are processor > nodes IIRC). Note we are trying to improve the cache description in QEMU > at the moment as it would definitely be better to present caches in PPTT, > but that isn't the main issue here. > Indeed, I just replied in the other thread that I clearly missed SMT. -- Regards, Sudeep