From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2610:1c1:1:606c::19:2]) by sourceware.org (Postfix) with ESMTPS id 80DFC3858C5E for ; Thu, 12 Oct 2023 17:18:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 80DFC3858C5E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 4S5xDh6Hx8z3b87; Thu, 12 Oct 2023 17:18:28 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4S5xDh5S7Hz3KFT; Thu, 12 Oct 2023 17:18:28 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1697131108; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=meekTZsCh6fRKRxTfm+CpeGxZ4eyyOdoZuWUuIqJPJA=; b=MAFi87pzUWyvBcAwcRo3UF9JCwFxbCpqTpUvZmVU1UVGtOfTrq6kW5cLad5HM4w1JQ9lcf Z6GHnRTNlfd5KzZasAblhq0lpTbYeG0FIzzzo4acs28aYZWyB5sTh6IQelW658XVnvfHq1 GbTIKfsM2hba8ViYg1XxiG0DRibYVSz9VSK3hGwN8u0rDetMZXN2Fw3WHibbPciY4ifSPd rlHXjGL120fJtAB3L43dDt2Ja2BwV/uqQMFJi1IlN8NYI2mTIesX85kWL2CwMn9URbTJC3 /ncbA8MK4oJvIGSwUsyapicXTQAciRk5UtvWFzllGMDWaauDbMgIs8kk3WvcRw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1697131108; a=rsa-sha256; cv=none; b=gXulrq9KzQ6EBnh/PKBsskgSvbgy3J3WHymEPKw0MWlKJ/5bz8Zd1pFVFjFGcA1x2nNpm0 Npb1i2NJhU2gukKlZef5Fe7rSkPiCCocjAuHPDl6F+fGXK+GXnyrrESuecdRQTC1BsUe8q gWt0O72elqtBqBgNw3LHDjw/XrLdhzcZw9GjEC+KfdOBfn1dmjYhIT/Ft0YdtqY+DxdhQY zVDj+o9ciFG9xQMU8YbmQPd5K9YMd1lfjFSzlyEGM+4WzB33zzSKxzNcNfR04t6iRf2Pi9 bIGon9fBD/QyUnMZd7p73/Zh+oX5N70rTbExCXN9i5os/t0YVdfrMwHQuTkxnw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1697131108; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=meekTZsCh6fRKRxTfm+CpeGxZ4eyyOdoZuWUuIqJPJA=; b=dsjuUJbvmkTJ4WiZ8RYLBV4HLte9vaTm+HMDBHYEVEG2pjJHVHH+aP2UZTvCG/uFgq+Oth v4APYvw3d0coBsSOo0mSqzD06Z+WaTJuZ7iRvt1beIg0+OaBaE1/kYObqGqjv7OD58zW/o 1zchm2i0nJHWFSB8aCx/9O4TgZ0GoFX+kqgd7Es2V/BOVhwF3RLngd3O/c8npf6TVA74NS RtUvq6xf21dLSWzom/eqxm7z7dJRl5TyUdXnZoYObU7cUI07bB4xkv7Mlj80Xb3Cycu/ZL ejsiV4fIjWmAKg+QH1wCqF6NhDj3f+qDspwbfbRqtJZrjwKoCIuMx17nccDEpQ== Received: from [IPV6:2601:648:8683:39a0:9500:c4f6:4efd:ddab] (unknown [IPv6:2601:648:8683:39a0:9500:c4f6:4efd:ddab]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4S5xDh1Wm8ztxh; Thu, 12 Oct 2023 17:18:28 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <53b0925d-04d5-a43b-0bd5-cf9e7d9db291@FreeBSD.org> Date: Thu, 12 Oct 2023 10:18:26 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [RFC 00/13] Proposal for a new NT_X86_CPUID core dump note Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org Cc: Felix , Jini Susan References: <20231009183617.24862-1-jhb@FreeBSD.org> <1fe75b09-7531-4d57-845c-c4a172af17fe@polymtl.ca> From: John Baldwin In-Reply-To: <1fe75b09-7531-4d57-845c-c4a172af17fe@polymtl.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 10/12/23 7:33 AM, Simon Marchi wrote: > > > On 2023-10-09 14:36, John Baldwin wrote: >> One of the shortcomings of the previous XSAVE patch series is that it >> depends on heuristics based on the total XSAVE register set size and >> XCR0 mask to infer layouts of the various register blocks for core >> dumps. This series introduces a new x86-specific core dump note >> intended to supplant these heuristics by storing the raw CPUID leaves >> describing the XSAVE layout in core dumps. >> >> This series proposes a new core dump note, NT_X86_CPUID (0x205), which >> contains an array of structures. Each structure describes an invidual >> CPUID sub-leaf containing both the inputs to CPUID (%eax and %ecx) and >> the outputs (%eax, %ebx, %ecx, and %edx) in a format roughly matching >> the follow C structure: >> >> struct cpuid_leaf >> { >> uint32_t leaf; >> uint32_t subleaf; >> uint32_t eax; >> uint32_t ebx; >> uint32_t ecx; >> uint32_t edx; >> }; >> >> This format is not XSAVE-specific and implementations could choose to >> add additional CPUID leaves to this structure if needed in the future. >> Consumers of this note should lookup the value of required leaves and >> ignore any unneeded leaves. >> >> An alternate approach might be to write out a more XSAVE-specific note >> that is an array containing the offset and size of each XSAVE region. > > Something I thought about: I think there are asymmetrical x86 processors > now, with "big" and "little" cores, not sure how they call them. For > them, is it possible for the XSAVE layout to be different per core, for > instance some cores supporting AVX512 and some cores not? And > therefore, will we eventually need to include CPUID / XSAVE information > for more than one CPU core type in the core file notes? (The Intel names are "P" (performance) and "E" (energy-efficient) cores btw) I have no idea if they use the same or different XSAVE layouts. It would seem to be a royal pain if they did as everytime a user thread migrated between cores the OS would have to convert the XSAVE block from one layout to the other. FreeBSD does not have any notion of multiple layouts today and just assumes that the XSAVE layout is uniform across all cores in a system. I believe Linux's kernel does the same from my reading. -- John Baldwin