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 2A3103858C36 for ; Fri, 27 Oct 2023 02:54:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2A3103858C36 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 2A3103858C36 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2610:1c1:1:606c::19:2 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1698375284; cv=pass; b=A7jzLmB6fvoog1thZpdGCc819ouRZURVJR0qU3RUacuyeAnLmtJZfL8/h4sel8d1aWn/Zvw8n0JlcK/RX0yIpjLII1V4tPdrtu+xMHYx0DSFpZaWgtt86kRKqeqR5Eiz2Lb/7DdlwDjLNFnfShYDUDlrbgnN4ks0He1ON19DyhA= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1698375284; c=relaxed/simple; bh=MpeZ89SmNwtMEFfaW/kkyq2qDRfhe2A+kM+aV4KAxB8=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=exiSmweznBNRANUBtVO9jDhsrvjt+mJoJC64FZ6VBeYIYCIJGekdoFWQVmiKzFay8Ip1PqgxquuKKztBl/tIpV1A1KREHM2ixq6h505HJ1pogTzaQVj7O1+crNi1CDQUUqW6zUOdSzqE1DRlV5ZJCHwEkQ85rYHnI1nMR9Uiyco= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (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 4SGnM26YR6z4PmJ; Fri, 27 Oct 2023 02:54:38 +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 4SGnM25kztz4VQP; Fri, 27 Oct 2023 02:54:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1698375278; 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=jWgIeIL5HVtq4Q5BGs6a/qY69Q0No6KkgFjBlpvBi4Q=; b=gjB1jtJM5Ft1+GUV9gM9y2bcsL7UKO169FohWmSIHVKGnLN+dszXXyR5mN6Y/X7y+am7n6 ksE5yLvRMjS5DCPlwB/Y1bNyVbTw2A8NQQn5drp4v0oiNN7mxuRClRwLW4sWx+5/CNs9jx j8jYaVNoWyAe20ZYcwfEwkffYWwU8wxB6A96CJ55OlcQ9zD97hqhJzmzlSMoXJZeZG3O/Q nN+zqAxtywKlVmhhv89onSGjH7SqEE7qYAeka44qpLIHKVBjvh2gnnPaiabzgo5NnEJcZl /fduPhQ4YaHRSqso3uu9X0blDQdRZHUJvZSvZ8RDX2fL4vmCr3s79xLRH2zx5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1698375278; 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=jWgIeIL5HVtq4Q5BGs6a/qY69Q0No6KkgFjBlpvBi4Q=; b=MWROQhSeDZ2PWjB72JartYfSRLJ7hypc5NGt8G/JuM9kqr/H0a7QP0yvslaXagqSP/rfR8 5pt8zYU22tfhtn9rgnYdhFpBKcsKTKmlmMkXuhOJNro1X/YcrA1NkQ0NDE9spf+gOhtpNW /Om97k5PGQ8TKG84BrjhvOeoKdBXnY78EskE9Xz0WZq19eWCwb3OQD1RuY+Qgf1Yz5PPNj n2zPaPobizEV9wkIhXGf+t2yBiTmGyBnzc2BcRUDS/aZ+BYCsI8Vgx1A8sKI2nFfsWBFuc HmiXNPgdwNXqVoGKS5iYvAD2LFpmw8MIZNQG9q/XU7EL6rYJGFKvVIKxM6H7UA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1698375278; a=rsa-sha256; cv=none; b=oH2KOv7AjcDybEAxMXXyILeSi+in2aVoMmXSTj4cq7/2X1cJrcpn4twvbCVs7UdcMcna9+ SbK1rrihq2hKg2BSsDSufcQQARQCPlbZbt3+uiW15/W2eVn2wv2NYOBpX7mai88GYIVi+F E7yIhziDZEY9LGkUSaEOY0CwvbzERrxo3HU4UmtGh/EkqB/veN0CUpkSdgbBzTeW5TByRt up0xVxpznssmCWJ6blPFIECRWV2XNjDvEejdlFDsa9AhxkYxezIJWvXSRP9tqxdhxmz6B1 uS5swtEqbn4ct1WKUNL/5xelHiSsrrrPbXPi+SqelJJfIRG+gr4RKvcs/cqvGQ== Received: from [10.0.0.43] (unknown [98.47.13.2]) (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 4SGnM217s8z5qR; Fri, 27 Oct 2023 02:54:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <1a7910b6-6e04-41c7-a274-85f9e203447b@FreeBSD.org> Date: Thu, 26 Oct 2023 19:53:13 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 00/13] Proposal for a new NT_X86_CPUID core dump note 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> <209db235-f5f8-ef21-a2d7-b0e06c752f11@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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/26/23 9:18 AM, George, Jini Susan wrote: > [AMD Official Use Only - General] > > I think it might be better to go with different NT_ values for the P and the E cores. We will also need to put in additional mapping information as to which core/ cpu id belongs to which core set (P or E). Hmm, do you mean mapping thread (LWP) IDs to specific core sets? Right now core dumps don't really include the mapping of threads to individual CPU cores, in part because threads can migrate between cores (subject to administrative and application constraints). I'm not really sure there is a use case for storing that information. One way you could store that would be to have a per-thread note storing the logical CPU mask (or cpuset, not sure which term Linux uses, FreeBSD uses cpuset) for each thread, but then you'd need perhaps some other note mapping logical CPU IDs to other CPU data. (For example, if you did have a separate NT_X86_CPUID_E_CORE, you could have some other note that was a short table mapping CPU IDs to CPUID notes (e.g. cpu 0 is NT_X86_CPUID, cpu 1 is NT_X86_CPUID, cpu 2 is NT_X86_CPUID_E_CORE). However, I'm not sure it makes sense to store all of that now without a use case. I do think though that this does show there are ways to extend the information in the future should a use case arrive. > Thanks > Jini. > >>> -----Original Message----- >>> From: John Baldwin >>> Sent: Tuesday, October 17, 2023 6:06 AM >>> To: George, Jini Susan ; Simon Marchi >>> ; gdb-patches@sourceware.org >>> Cc: Felix ; Balasubrmanian, Vignesh >>> >>> 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/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 > -- John Baldwin