From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id C03B83858D37 for ; Tue, 17 Oct 2023 00:36:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C03B83858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C03B83858D37 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=96.47.72.81 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697502977; cv=pass; b=eTGMv9+R8iczWUmOngnpXphPSW8/1vh8IFsoAKSmZaa7Mfk6XK+Qof+FtSV1Kl60vu9aJ8vsBXpl1zTq3qGLHj7vMLcrLty8fo2fY0NezSdsWM+8foR2q7m524rWaeywuAyWSXi4jGQS4hJkqGWzsGge2DY6pQExCxmpXb1aaT8= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1697502977; c=relaxed/simple; bh=ImaqCTi2Gka0PDQyyDtZs6raABoAu7vVOo8h4UXqzDY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=guwCwfKuFb9YZrz52iXrl99+s31jkOnmktFRMdGcJTRgWLT98AKiPT/GFN9Y/HuMkx12HTsgVDKyp6e8h7DExVa3VNEkoUTTpnt4MpDtIFy9sBKicaNOaNYzBu3Px/b3Mjrr/Y84cGyEvSGhnh9AKMJ8kWUQtls8sCXmr4LOarg= ARC-Authentication-Results: i=2; server2.sourceware.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 4S8Zlz4WT6z4BvX; Tue, 17 Oct 2023 00:36:15 +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 4S8Zlz3jhtz3Mtl; Tue, 17 Oct 2023 00:36:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1697502975; 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=uj/EQLdD1ejuuhLxCCkoOpTVn6WOrawgQO8s8/MWUWI=; b=ne8DUeR9i7/ESkPK9ANxfIpy6kJ7VFvbHcsnq4pNMgx73eQI5inVtp2sAr7XJZLjgJPX4Q fqkCTiGX2UDBuKOfY1PiCWQDS/a68Jx030HFHVB3FFgZr5L8GYjQfOrG+NKD8zffDT7Zvp qh8UKKPMVnjYcVFaUkRq/ZXQuRs62n53YuxxS00bsq32KDhSFn/f4QeDHj2TCvxOxhzio2 65fMvTtMu1K+xACvV4m0wA+034mppMl39QRqHwW9WqOkGeaBCu6kKJ5BkHYkuNKaJJsiLX EJWVQTI2mtGi91oHgW03XYDC9bSxWJyO2RkVW6GW87MGDmvEMwmhpDmyYoq9Lg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1697502975; a=rsa-sha256; cv=none; b=Id7ODh+RNYcZuIzQ5WCTg6PWAj2QCF1pMYhlmptVIID4XyIrOnIDEEIJa226eQ3WikTX4S YCV+LAYPRvSSRm6YDLzAocOB4nBl2ypuBGQyjLwUeQagdjJCL6yS2Gd+tpV/C3JzqtrC4g hMfD7Jt02TMLyWRfggVPJcD2sB318zMIOSMlPsx1pEFLxseDP0RTJ8C9XQm/2W58GmiM7R wH2SHfUrUIWqpNAOBjddNZCztakTX/xmkM/JMVrOcAz0v0s7apbFdU0TeLfA2VQW+v6FGT EpuKmBbBw1I01+4PkF1GdaoHmisn/Bfc6c3rwRV3Vtl0tDhqmDr5bLfvjxNqUQ== 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=1697502975; 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=uj/EQLdD1ejuuhLxCCkoOpTVn6WOrawgQO8s8/MWUWI=; b=Ei5If4TWSkXr33ZekifY9l8gxE5kRvf64vrPEZSpFd9vD4WdmvMMTauQ9rSb14E8UNtsUf o3IPnbLWXR4s4VmExqNRROi3pBJYKNd6ql8ho1e0GPcyqh/knB2p+Zn2B9RNZXJGP27YcU g6atXKIWJotrOGlJyvB15jadh0zdP0HRE+N1WHIGE5dWsLzZ8nmHCZGEDiTwkTexfvybP8 0sV33LvZOmA2YrDRd8lhtCUpxI9sged0Xmj+ZMDSdkHxEcdHsabB734o2ZsrHkh2r+UG5K Shx9p+nF1VCtti2TWFPxFDIgr56GgWhPoHzaqZa4URnp1ay6nWShPZTmNvtj7Q== Received: from [IPV6:2601:648:8683:39a0:f055:f679:76c4:bebe] (unknown [IPv6:2601:648:8683:39a0:f055:f679:76c4:bebe]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4S8Zly67rkzvSp; Tue, 17 Oct 2023 00:36:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <209db235-f5f8-ef21-a2d7-b0e06c752f11@FreeBSD.org> Date: Mon, 16 Oct 2023 17:36:13 -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 Content-Language: en-US To: "George, Jini Susan" , Simon Marchi , "gdb-patches@sourceware.org" Cc: Felix , "Balasubrmanian, Vignesh" References: <20231009183617.24862-1-jhb@FreeBSD.org> <1fe75b09-7531-4d57-845c-c4a172af17fe@polymtl.ca> <53b0925d-04d5-a43b-0bd5-cf9e7d9db291@FreeBSD.org> From: John Baldwin Subject: Re: [RFC 00/13] Proposal for a new NT_X86_CPUID core dump note In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,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/13/23 2:38 AM, George, Jini Susan wrote: > [AMD Official Use Only - General] > > I think that even if the xsave layout remains uniform across the cores of a system, since we are trying to design an extensible .note section which can possibly hold all kinds of CPUID information, we might want to consider various scenarios wherein the CPUID information might differ across cores (esp for big.LITTLE/(P/E)), like the cache information, perhaps ? It might be more prudent to include the coretype information also in such cases ? It's certainly occurred to me that it might be prudent to include the full complement of CPUID leaves even in the initial version of this note should that information prove useful in the future. However, I'm not quite sure how we should "name" the different CPUID leaf sets in this case (e.g. the set for E cores vs the set for P cores). In particular, it's not quite clear to me how many sets future systems might have? One route is to use additional NT_ values for different sets, (e.g. a NT_X86_CPUID_E_CORE or some such if the "default" set is for the P core). We could also embed an identifier at the start of a note, e.g. a 32-bit integer, and dump one note per set, so you have always have a note for set 0, but in a system with E cores you might have a set 1 where the convention would be P cores are set 0, and E cores are set 1. Future systems with multiple core types would have to decide what type of mapping to use between core types and set IDs. One issue with the second approach is if you want these notes accessible via ptrace() and not just in cores, it wouldn't be clear how to request the leaves for set N if they all share the NT_* value. > Rgds > Jini. > >>> -----Original Message----- >>> From: John Baldwin >>> Sent: Thursday, October 12, 2023 10:48 PM >>> To: Simon Marchi ; gdb-patches@sourceware.org >>> Cc: Felix ; George, Jini Susan >>> >>> Subject: Re: [RFC 00/13] Proposal for a new NT_X86_CPUID core dump note >>> >>> Caution: This message originated from an External Source. Use proper caution >>> when opening attachments, clicking links, or responding. >>> >>> >>> 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 > -- John Baldwin