From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030247AbdJRKZA (ORCPT ); Wed, 18 Oct 2017 06:25:00 -0400 Received: from mail-by2nam03on0072.outbound.protection.outlook.com ([104.47.42.72]:14767 "EHLO NAM03-BY2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S936784AbdJRKYy (ORCPT ); Wed, 18 Oct 2017 06:24:54 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Tomasz.Nowicki@cavium.com; Subject: Re: [PATCH v3 1/7] ACPI/PPTT: Add Processor Properties Topology Table parsing To: Tomasz Nowicki , Jeremy Linton , linux-acpi@vger.kernel.org Cc: mark.rutland@arm.com, Jonathan.Zhang@cavium.com, Jayachandran.Nair@cavium.com, lorenzo.pieralisi@arm.com, austinwc@codeaurora.org, linux-pm@vger.kernel.org, jhugo@codeaurora.org, gregkh@linuxfoundation.org, sudeep.holla@arm.com, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, will.deacon@arm.com, wangxiongfeng2@huawei.com, viresh.kumar@linaro.org, hanjun.guo@linaro.org, catalin.marinas@arm.com, ahs3@redhat.com, linux-arm-kernel@lists.infradead.org References: <20171012194856.13844-1-jeremy.linton@arm.com> <20171012194856.13844-2-jeremy.linton@arm.com> <38c63cfd-4c13-9461-0d4a-74b0943be0fd@semihalf.com> <2ce92b90-fc2c-3fff-a3e3-b9517057ab2c@arm.com> <4ee4af4d-d987-33f9-4d55-67bfede3ebfa@caviumnetworks.com> From: Tomasz Nowicki Message-ID: Date: Wed, 18 Oct 2017 12:24:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <4ee4af4d-d987-33f9-4d55-67bfede3ebfa@caviumnetworks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Originating-IP: [31.172.191.173] X-ClientProxiedBy: AM0PR0102CA0066.eurprd01.prod.exchangelabs.com (2603:10a6:208::43) To CY4PR0701MB3650.namprd07.prod.outlook.com (2603:10b6:910:93::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d3654a70-a6e1-49ac-cba6-08d516127746 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075);SRVR:CY4PR0701MB3650; X-Microsoft-Exchange-Diagnostics: 1;CY4PR0701MB3650;3:FRt4fE/dynP6fIVlifHWm3VaYAnN9W3PCf3lX4hM22INjQx/FcSeJcE/NGszrvE6cn4BzDD8XbK8JeIlSuzzctZZ+4qRfIYWK8JbfYa9BEj+IDYtJr6Cdb5dRI+vUpoxupiIZjCZ22UUxd2c9S9mQtA3bQD95iJ+AtyJjtQiGp+2ujqqbE3ktlqrE47NSHVolRDUjNgFt2Q9BtmfTiLU/VDTZQ36qS9VBu74xei7q0vToPVtkvGuZE7lTgsBnk2Q;25:rDeJoFAsJUYwLWhTdRozA4uqNrTxjeuRsLVDIBvosYVmG2Q4aiO9vej1++aLhkiP9skM7/a103vdLlt2+tPBWdHzzzSA6YqsWDuj95Jqq1GtDpgMKXOic8yIvNMM+K4lFlsNyhkWCMlFpe6dxHbhTzr9KndK9lPXkgAJSMKgdP8bNK5Bu4v93nWrOOmjrVVF4G7nkMznN5RDm8RPD26XEFGo6Nqr9QUrq4hfds+5dym+EXGjcs6hpujqwMsGwv1ah9lshx2uy+fUD5XpKY85Y+MpkEd5lp18omL07mZ+w+lufmMNYaokwi3u3FmlyuTtuUaVoFET/BhWPiaf4pjGwg==;31:NIiqrtrjBUqA8Ee2Fs0uFKAz6lkleltP828AaLV2TkhXyMdBMxPx4i3MU4tL8dcwsDfso1lc66ZRL9R81gS3VPZcKlIX6tDLLJssNaBxjsnpo81PTyQKQHjLntbsDISErv+rosqGaLAmyNn2wsaQMxALeM6TX4AtnCSJKmqoSBi5rguheSdbXFxN64zvzIdFRYJSnR9uDKvWn4pBPab4mqVACoyW9S4CQGJ8qqYV/QQ= X-MS-TrafficTypeDiagnostic: CY4PR0701MB3650: X-Microsoft-Exchange-Diagnostics: 1;CY4PR0701MB3650;20:vC9VUfSKXCGQURBZGLdy3w29sXnq6zrMovD3ndSP6HQNoGnWw0JW26ibLtXPE5pgWlP3XykFnGAzQ80VEJzfFgPUuG+VPcaV6Ewlsfezja8X4OP/mgeUBHJp4Vs4OtxWI7j7Yca36JbWPnFvtPP/RO3MBQsHTeZ3k5SMHZu/EkXlcDiY0llN5pgQvOKTIW0Bhs4FOAFDTg07wqpJs0afrn4OrjwBXghUfj+EjpbXhPuJV368BqkXC1clJ5mfu1BWqukd61JdQU0sf9TcEXtNBLOELimXIxi7U5XpgK3gCHZcH0vBQLNHuOTVBrM2R7bIkNkyyH6upREXjfzOpeDpUY/+l8tfq3Z3PyFQt/NPhPoqpOtzdw0Ca/BAXrRYwXyJj/mz0Wi4Fb7GEQobcuQ1+8YVUu1j0L4/2BquypIGdHzwjSmV2l8J2b+TzUzdMVpYjS8XXL+jArY2by6sZFKI9DvRSH38GPLhYViyB5vRatBOl+tkqpeeRczvrvV7OCCTlq1bvAq3yZ4RrhkDdtlm6j+AD9lg8Ag8dwz95D5ABzWZQFAI+HlfSy9DK9JBagKoxIM6QcB0l3obrKTpyBVpLLfYrb8930IT8oYzXBbOwZ8=;4:f/d8/RmF896OiVnl+JK+alFaQK3Iur0WGe6ciJqc+b7AD/GNh4t7DiQS22AbD3gcc5sUlF4GjqJWlCkeGZbfw/UgiatItK3ANpDAx1nHpW8+IYgG1iccU11YXKKLZY8iwitjekNeNBiqHAhJuL0eRMCwx4SNkHYIxied60pF/yPzg81n2g/ZN7l+k4vUnL6s2PTWPp850QS3MB4bQcBd8tH8N1fxLoqDq1lQePq2dXkbzfaCx5tmUQoweZK+Ll/DmMSrtEbCscEXokgP8D31Vl6x0NeT23L1mWuZKGKgbkk= X-Exchange-Antispam-Report-Test: UriScan:(180628864354917); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(100000703101)(100105400095)(3002001)(6041248)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:CY4PR0701MB3650;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY4PR0701MB3650; X-Forefront-PRVS: 0464DBBBC4 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(6009001)(346002)(376002)(199003)(189002)(24454002)(377454003)(47776003)(31686004)(65956001)(66066001)(2906002)(64126003)(2950100002)(50466002)(105586002)(106356001)(6246003)(110136005)(68736007)(93886005)(33646002)(53546010)(58126008)(42882006)(6666003)(316002)(97736004)(4326008)(16576012)(53936002)(2870700001)(7416002)(81166006)(478600001)(229853002)(77096006)(8676002)(25786009)(305945005)(8936002)(81156014)(7736002)(5660300001)(23676002)(16526018)(72206003)(6116002)(3846002)(101416001)(36756003)(54356999)(50986999)(83506001)(31696002)(189998001)(6486002)(76176999)(2004002);DIR:OUT;SFP:1101;SCL:1;SRVR:CY4PR0701MB3650;H:[10.0.0.85];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjA3MDFNQjM2NTA7MjM6ZnZNZlJHaFdrczVmb1VCNmxoK3BuVXBy?= =?utf-8?B?WmlLb042ZWowTEFEbHNRdllPSlo2NGpoZExCYzNLL3lHSHF6MXpaZEx5SFda?= =?utf-8?B?WVQ1MmdaWmhmckN0UWdUdGVsaHk5YW85MjZudnFPRmkwbjZienFYd2NkRUJM?= =?utf-8?B?TmttQ1B2c215SXUwd2lDOW5qUzM0aG5IT2pWUGNhWG5EOWhQMXVQem90WTY0?= =?utf-8?B?dGhHQ1Mxd3dxdmFLK1NtL3NRbXovUnNkeFlaQitvZEladHVPZFlNYWFCZWdX?= =?utf-8?B?Ynhsc0ZkMHI0K29Ja2x1YXpRRmJaM0g2TDRhNFBLaDI4VVBwNEQ2c1BZdFF0?= =?utf-8?B?M3E3dWgyb3MzLy81L3R3bWM5UjBjVzhaQ1ZFQkg4QTZPdXNrdUZ2RWlQWUc2?= =?utf-8?B?SlcwVGltZFlCd05QY3BudFdSb0QvcmtqMGtTcnFlaWk0U21JdVkrUVhRQy9D?= =?utf-8?B?ZjhmV2FHM1N6TTFwYTJvQmZSbEdNRG9uQTNVb052VG5TMTdaQk9yVkJWT3oz?= =?utf-8?B?MndEeVhwcytYdncrNExzOThuQmFRMFc5U0VGL21RSnppU0gzN0d1SGFrZXYv?= =?utf-8?B?MGorMm5SRXFRR3hMaU41UEJxMUM4UU04M0wyMzJZTXo5VW1uclpMcUtNcFR4?= =?utf-8?B?aFQvclJXbkw1WURMenVqRlg1R3pXTE1jWHV1ZVlMdUVNVXFMVTNxUzNVRzBB?= =?utf-8?B?V3JlVTRhVWJBak9neDRuVGlWdlhJNEE5ay9RaG4xY2dUenA3bWVvbTE2a2M2?= =?utf-8?B?QVJoYU9JMnR6R3dCUFlGZExhV0ZONlh6ZUZ4Ny9CRTRuYmVORi8rV1g0U3ZB?= =?utf-8?B?YlViTzUwZFJ0ZWhNRGFpKzBJcGZWT0E4cVliWHFaTXdVRGxKUWdUUUlQRHUr?= =?utf-8?B?VlpYZ2lKbVB1T2J0UFpIVWh5L2ppT1pyNUxwRWUvWEg3V3ordnVwNkhyU3Vu?= =?utf-8?B?ZnNpaVZtMktESDZPNGwwQ1A0ejN4R2FGcXM0eFRObVNFYkdYc0dSUWQ5a2gz?= =?utf-8?B?cTMwMnRtd1dLRnQ2WkhPS1VkOTdlUzJmVnE2SUExMjBoNWx4M2ZTaW1OTHhh?= =?utf-8?B?MmJzODlTS1crT3BDQlBKakF2TXJTQkFicEFOazFvL3F0cHJRcG10QkRVbGJm?= =?utf-8?B?ZU9PU1dTSzZ4M3psTE1VanUyRWxMVXl5TzlCYytnd3FBYlBKZXNmbU52V1hi?= =?utf-8?B?V0ZFSS8xZUU2MlQvUVNyaWRvR1NPS2xmNWpXQzhuY3lweGx3ZDdGU2ZMY3Yw?= =?utf-8?B?VHkwWEY4a0haSHltenBvYkg0Z2ROQ2RRaVY1ZllMZkptNTJyMUEzN1JkbWxP?= =?utf-8?B?NHV0STlteHhIaTFJTlpMUktmT0xhSzNYQkhvQjN5bGo3ZklrZjFSQjBXZjJS?= =?utf-8?B?OWZtS2k4T1NaVnhLeGRQRWMzck5wT281a25ubE9EZDdXWjNydWk2bjdwYlFj?= =?utf-8?B?clorOXdLbUpUYmllaGczSFg2eHFwRzRweHF4Tml6WGVhbEFYeTdLUG9hVEpL?= =?utf-8?B?dDJvOFlQUEVORHZoSjF3WmpYd2EyVjI2M0ZvUGpBRUd0QWVMMFRKVkVsb0l3?= =?utf-8?B?QllHa1hLaUNqK3dDSktjMmhFSExpOUY0OTl4TWg2bE0vNGRiaENhdGNrNCtq?= =?utf-8?B?VDZMcFZVa25zRWtkeURxK2ZXcCtPTW1MUDh0WldIMmtsY01VWm5zT3hvWTlC?= =?utf-8?B?ZExrWjFMcnhXdGcyc0puMm8rUGFxUkgyRkYzMFVBR3RTMFJNTkhMOFpKVjd4?= =?utf-8?B?UmsxZ3BGYjBnM2ZvelZENlZPZHF4T2hxdXFxMGdDaTJXcFMzT0RmL013UU51?= =?utf-8?B?WXJDejMyLzAweDc4Z3NHQUdVSnpPVVc2bE9ZdGlCWnhYRm1Gem5qRXVoTVd0?= =?utf-8?Q?E5/0blXZMslo0=3D?= X-Microsoft-Exchange-Diagnostics: 1;CY4PR0701MB3650;6:JHkrFqR8TTiIbtMVNTH5opP3CCH5Mddw+aGvZOG4A/34h4DHtoccZ9oPwZ1XtXnnHXAit3GkUUJjIf4e50mwLZWTs3jLSIKSL9Is12kwGoG/xHchmDkSBi1rU2+Fg0sCoJtuLxvufb6TR8oFt7Cok+lElDSEC3XnydQAEX22hZRmpsb8lOwKAlAH+NIl/DJ4HC0qftO/M4DP45TJqGKyusRZvoH1UQaGvXzK5WXXYN5OikILqTJ5++hw84AGQkUickMgSCKqni1h2xM/pGvh7Bo+LXs1ydPbV0kf3zHkHunoyekbDzX/0td8ijTs6ZNyE1zW7sUAaoW9GWqORDj5lg==;5:rNm0KCOCXHYXunA0pbPEVeU2Wwf+PhkaF/4qJcz9dFMPgmbDRGO0PDKhCobkh4HCm++KUaqjkXOdPiKpDbpA710V6y49S4jRnJRRj+Iqq6UHkrnfKJ/gKuX+TyOBykz7PeBgh0t4YHx12qioN9stHbBQZyFgA2e7uAETaJKG5aE=;24:+HJIBWPdisvzlOz/tDfOmypZj7kBdTxHW5PItkeXT0GEBfnwpzPMnmtCOT+gJnaeltfuPO9gNgwCiSGGXIBGzgWO4L0nCH4+0Ivii0NH3XE=;7:24OUu6nO/yDe54xqsBSujrIhVOOuEZAi7FucpXlyHo54fmz72G/fNHjt8EIT+bKEh6BipAq0v7E9UU4DDyZkIzLUYTFzzcK1XAjePRVYlzE9XMAJjNuNIEWFzABT92/FleMuC4P+O4YLPZ1sV4aBXFe8p9fVRJyaxYvCt2IFGE1VQzNUCJKc+LCi0tZgQP2CwpPBhtCwpSrJ91paHGKFBj4mUjXtiClJr8pR8IaNd3k= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2017 10:24:47.0862 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0701MB3650 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18.10.2017 07:39, Tomasz Nowicki wrote: > Hi, > > On 17.10.2017 17:22, Jeremy Linton wrote: >> Hi, >> >> On 10/17/2017 08:25 AM, Tomasz Nowicki wrote: >>> Hi Jeremy, >>> >>> I did second round of review and have some more comments, please see >>> below: >>> >>> On 12.10.2017 21:48, Jeremy Linton wrote: >>>> ACPI 6.2 adds a new table, which describes how processing units >>>> are related to each other in tree like fashion. Caches are >>>> also sprinkled throughout the tree and describe the properties >>>> of the caches in relation to other caches and processing units. >>>> >>>> Add the code to parse the cache hierarchy and report the total >>>> number of levels of cache for a given core using >>>> acpi_find_last_cache_level() as well as fill out the individual >>>> cores cache information with cache_setup_acpi() once the >>>> cpu_cacheinfo structure has been populated by the arch specific >>>> code. >>>> >>>> Further, report peers in the topology using setup_acpi_cpu_topology() >>>> to report a unique ID for each processing unit at a given level >>>> in the tree. These unique id's can then be used to match related >>>> processing units which exist as threads, COD (clusters >>>> on die), within a given package, etc. >>>> >>>> Signed-off-by: Jeremy Linton >>>> --- >>>>   drivers/acpi/pptt.c | 485 >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>   1 file changed, 485 insertions(+) >>>>   create mode 100644 drivers/acpi/pptt.c >>>> >>>> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c >>>> new file mode 100644 >>>> index 000000000000..c86715fed4a7 >>>> --- /dev/null >>>> +++ b/drivers/acpi/pptt.c >>>> @@ -0,1 +1,485 @@ >>>> +/* >>>> + * Copyright (C) 2017, ARM >>>> + * >>>> + * This program is free software; you can redistribute it and/or >>>> modify it >>>> + * under the terms and conditions of the GNU General Public License, >>>> + * version 2, as published by the Free Software Foundation. >>>> + * >>>> + * This program is distributed in the hope it will be useful, but >>>> WITHOUT >>>> + * ANY WARRANTY; without even the implied warranty of >>>> MERCHANTABILITY or >>>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public >>>> License for >>>> + * more details. >>>> + * >>>> + * This file implements parsing of Processor Properties Topology >>>> Table (PPTT) >>>> + * which is optionally used to describe the processor and cache >>>> topology. >>>> + * Due to the relative pointers used throughout the table, this >>>> doesn't >>>> + * leverage the existing subtable parsing in the kernel. >>>> + */ >>>> +#define pr_fmt(fmt) "ACPI PPTT: " fmt >>>> + >>>> +#include >>>> +#include >>>> +#include >>>> + >>>> +/* >>>> + * Given the PPTT table, find and verify that the subtable entry >>>> + * is located within the table >>>> + */ >>>> +static struct acpi_subtable_header *fetch_pptt_subtable( >>>> +    struct acpi_table_header *table_hdr, u32 pptt_ref) >>>> +{ >>>> +    struct acpi_subtable_header *entry; >>>> + >>>> +    /* there isn't a subtable at reference 0 */ >>>> +    if (!pptt_ref) >>>> +        return NULL; >>>> + >>>> +    if (pptt_ref + sizeof(struct acpi_subtable_header) > >>>> table_hdr->length) >>>> +        return NULL; >>>> + >>>> +    entry = (struct acpi_subtable_header *)((u8 *)table_hdr + >>>> pptt_ref); >>>> + >>>> +    if (pptt_ref + entry->length > table_hdr->length) >>>> +        return NULL; >>>> + >>>> +    return entry; >>>> +} >>>> + >>>> +static struct acpi_pptt_processor *fetch_pptt_node( >>>> +    struct acpi_table_header *table_hdr, u32 pptt_ref) >>>> +{ >>>> +    return (struct acpi_pptt_processor >>>> *)fetch_pptt_subtable(table_hdr, pptt_ref); >>>> +} >>>> + >>>> +static struct acpi_pptt_cache *fetch_pptt_cache( >>>> +    struct acpi_table_header *table_hdr, u32 pptt_ref) >>>> +{ >>>> +    return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, >>>> pptt_ref); >>>> +} >>>> + >>>> +static struct acpi_subtable_header *acpi_get_pptt_resource( >>>> +    struct acpi_table_header *table_hdr, >>>> +    struct acpi_pptt_processor *node, int resource) >>>> +{ >>>> +    u32 ref; >>>> + >>>> +    if (resource >= node->number_of_priv_resources) >>>> +        return NULL; >>>> + >>>> +    ref = *(u32 *)((u8 *)node + sizeof(struct acpi_pptt_processor) + >>>> +              sizeof(u32) * resource); >>>> + >>>> +    return fetch_pptt_subtable(table_hdr, ref); >>>> +} >>>> + >>>> +/* >>>> + * given a pptt resource, verify that it is a cache node, then walk >>>> + * down each level of caches, counting how many levels are found >>>> + * as well as checking the cache type (icache, dcache, unified). If a >>>> + * level & type match, then we set found, and continue the search. >>>> + * Once the entire cache branch has been walked return its max >>>> + * depth. >>>> + */ >>>> +static int acpi_pptt_walk_cache(struct acpi_table_header *table_hdr, >>>> +                int local_level, >>>> +                struct acpi_subtable_header *res, >>>> +                struct acpi_pptt_cache **found, >>>> +                int level, int type) >>>> +{ >>>> +    struct acpi_pptt_cache *cache; >>>> + >>>> +    if (res->type != ACPI_PPTT_TYPE_CACHE) >>>> +        return 0; >>>> + >>>> +    cache = (struct acpi_pptt_cache *) res; >>>> +    while (cache) { >>>> +        local_level++; >>>> + >>>> +        if ((local_level == level) && >>>> +            (cache->flags & ACPI_PPTT_CACHE_TYPE_VALID) && >>>> +            ((cache->attributes & ACPI_PPTT_MASK_CACHE_TYPE) == >>>> type)) { >>> >>> Attributes have to be shifted: >>> >>> (cache->attributes & ACPI_PPTT_MASK_CACHE_TYPE) >> 2 >> >> Hmmm, I'm not sure that is true, the top level function in this >> routine convert the "linux" constant to the ACPI version of that >> constant. In that case the "type" field is pre-shifted, so that it >> matches the result of just anding against the field... That is unless >> I messed something up, which I don't see at the moment (and the code >> of course has been tested with PPTT's from multiple people at this >> point). > > For ThunderX2 I got lots of errors in dmesg: > Found duplicate cache level/type unable to determine uniqueness > > So I fixed "type" macros definitions (without shifting) and shift it > here which fixes the issue. As you said, it can be pre-shifted as well. > >> >> >>> >>>> +            if (*found != NULL) >>>> +                pr_err("Found duplicate cache level/type unable to >>>> determine uniqueness\n"); Actually I still see this error messages in my dmesg. It is because the following ThunderX2 per-core L1 and L2 cache hierarchy: Core ------------------ | | | L1i ----- | | | | | ----L2 | | | | | L1d ----- | | | ------------------ In this case we have two paths which lead to L2 cache and hit above case. Is it really error case? Thanks, Tomasz