From: "Balasubrmanian, Vignesh" <vigbalas@amd.com>
To: Thomas Gleixner <tglx@linutronix.de>,
"Balasubrmanian, Vignesh" <Vignesh.Balasubrmanian@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-toolchains@vger.kernel.org"
<linux-toolchains@vger.kernel.org>
Cc: "mpe@ellerman.id.au" <mpe@ellerman.id.au>,
"npiggin@gmail.com" <npiggin@gmail.com>,
"christophe.leroy@csgroup.eu" <christophe.leroy@csgroup.eu>,
"aneesh.kumar@kernel.org" <aneesh.kumar@kernel.org>,
"naveen.n.rao@linux.ibm.com" <naveen.n.rao@linux.ibm.com>,
"ebiederm@xmission.com" <ebiederm@xmission.com>,
"keescook@chromium.org" <keescook@chromium.org>,
"x86@kernel.org" <x86@kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"Petkov, Borislav" <Borislav.Petkov@amd.com>,
"George, Jini Susan" <JiniSusan.George@amd.com>,
"matz@suse.de" <matz@suse.de>,
"binutils@sourceware.org" <binutils@sourceware.org>,
"jhb@FreeBSD.org" <jhb@FreeBSD.org>,
"felix.willgerodt@intel.com" <felix.willgerodt@intel.com>
Subject: Re: [PATCH v2 1/1] x86/elf: Add a new .note section containing Xfeatures information to x86 core files
Date: Wed, 22 May 2024 18:42:55 +0530 [thread overview]
Message-ID: <4a090901-9705-40aa-ac3d-d67c52660f22@amd.com> (raw)
In-Reply-To: <87wmo4o3r4.ffs@tglx>
On 5/8/2024 6:32 PM, Thomas Gleixner wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On Tue, May 07 2024 at 15:23, Vignesh Balasubramanian wrote:
>> +struct xfeat_component {
>> + u32 xfeat_type;
>> + u32 xfeat_sz;
>> + u32 xfeat_off;
>> + u32 xfeat_flags;
>> +} __packed;
> Why repeating xfeat_ for all member names?
>
> u32 type;
> u32 size;
> u32 offset;
> u32 flags;
>
> is sufficient and obvious, no?
>
>> +enum custom_feature {
>> + FEATURE_XSAVE_FP = 0,
>> + FEATURE_XSAVE_SSE = 1,
>> + FEATURE_XSAVE_YMM = 2,
>> + FEATURE_XSAVE_BNDREGS = 3,
>> + FEATURE_XSAVE_BNDCSR = 4,
>> + FEATURE_XSAVE_OPMASK = 5,
>> + FEATURE_XSAVE_ZMM_Hi256 = 6,
>> + FEATURE_XSAVE_Hi16_ZMM = 7,
>> + FEATURE_XSAVE_PT = 8,
>> + FEATURE_XSAVE_PKRU = 9,
>> + FEATURE_XSAVE_PASID = 10,
>> + FEATURE_XSAVE_CET_USER = 11,
>> + FEATURE_XSAVE_CET_SHADOW_STACK = 12,
>> + FEATURE_XSAVE_HDC = 13,
>> + FEATURE_XSAVE_UINTR = 14,
>> + FEATURE_XSAVE_LBR = 15,
>> + FEATURE_XSAVE_HWP = 16,
>> + FEATURE_XSAVE_XTILE_CFG = 17,
>> + FEATURE_XSAVE_XTILE_DATA = 18,
>> + FEATURE_MAX,
>> + FEATURE_XSAVE_EXTENDED_START = FEATURE_XSAVE_YMM,
>> + FEATURE_XSAVE_EXTENDED_END = FEATURE_XSAVE_XTILE_DATA,
>> +};
> Why can't this use the existing 'enum xfeature' which is providing
> exactly the same information already?
First version of patch was similar to what you mentioned here and other
review comments to use existing kernel definitions.
https://lore.kernel.org/linux-mm/20240314112359.50713-1-vigbalas@amd.com/T/
As per the review comment
https://lore.kernel.org/linux-mm/20240314162954.GAZfMmAnYQoRjRbRzc@fat_crate.local/
, modified the patch to be a independent of kernel internal definitions.
Though this enum and below function "get_sub_leaf" are not useful now,
it will be required when we extend for a new/different features.
Please let us know your suggestions.
I will fix all other review comments in my next version.
>> +#ifdef CONFIG_COREDUMP
>> +static int get_sub_leaf(int custom_xfeat)
>> +{
>> + switch (custom_xfeat) {
>> + case FEATURE_XSAVE_YMM: return XFEATURE_YMM;
>> + case FEATURE_XSAVE_BNDREGS: return XFEATURE_BNDREGS;
>> + case FEATURE_XSAVE_BNDCSR: return XFEATURE_BNDCSR;
>> + case FEATURE_XSAVE_OPMASK: return XFEATURE_OPMASK;
>> + case FEATURE_XSAVE_ZMM_Hi256: return XFEATURE_ZMM_Hi256;
>> + case FEATURE_XSAVE_Hi16_ZMM: return XFEATURE_Hi16_ZMM;
>> + case FEATURE_XSAVE_PT: return XFEATURE_PT_UNIMPLEMENTED_SO_FAR;
>> + case FEATURE_XSAVE_PKRU: return XFEATURE_PKRU;
>> + case FEATURE_XSAVE_PASID: return XFEATURE_PASID;
>> + case FEATURE_XSAVE_CET_USER: return XFEATURE_CET_USER;
>> + case FEATURE_XSAVE_CET_SHADOW_STACK: return XFEATURE_CET_KERNEL_UNUSED;
>> + case FEATURE_XSAVE_HDC: return XFEATURE_RSRVD_COMP_13;
>> + case FEATURE_XSAVE_UINTR: return XFEATURE_RSRVD_COMP_14;
>> + case FEATURE_XSAVE_LBR: return XFEATURE_LBR;
>> + case FEATURE_XSAVE_HWP: return XFEATURE_RSRVD_COMP_16;
>> + case FEATURE_XSAVE_XTILE_CFG: return XFEATURE_XTILE_CFG;
>> + case FEATURE_XSAVE_XTILE_DATA: return XFEATURE_XTILE_DATA;
>> + default:
>> + pr_warn_ratelimited("Not a valid XSAVE Feature.");
>> + return 0;
>> + }
>> +}
> This function then maps the identical enums one to one. The only actual
> "functionality" is the default case and that's completely pointless.
thanks,
vigneshbalu.
next prev parent reply other threads:[~2024-05-22 13:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 9:53 [PATCH v2 0/1] Add XSAVE layout description to Core files for debuggers to support varying XSAVE layouts Vignesh Balasubramanian
2024-05-07 9:53 ` [PATCH v2 1/1] x86/elf: Add a new .note section containing Xfeatures information to x86 core files Vignesh Balasubramanian
2024-05-07 23:40 ` kernel test robot
2024-05-08 0:13 ` kernel test robot
2024-05-08 8:04 ` Kees Cook
2024-05-08 13:02 ` Thomas Gleixner
2024-05-22 13:08 ` Balasubrmanian, Vignesh
2024-05-22 13:12 ` Balasubrmanian, Vignesh [this message]
2024-05-22 15:34 ` Borislav Petkov
[not found] ` <902b1bf0-15e6-42df-8f86-21387deef437@amd.com>
2024-05-23 14:45 ` Borislav Petkov
2024-05-26 4:54 ` Balasubrmanian, Vignesh
2024-05-26 9:05 ` Borislav Petkov
2024-05-31 9:19 ` Balasubrmanian, Vignesh
2024-05-31 10:58 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4a090901-9705-40aa-ac3d-d67c52660f22@amd.com \
--to=vigbalas@amd.com \
--cc=Borislav.Petkov@amd.com \
--cc=JiniSusan.George@amd.com \
--cc=Vignesh.Balasubrmanian@amd.com \
--cc=aneesh.kumar@kernel.org \
--cc=binutils@sourceware.org \
--cc=christophe.leroy@csgroup.eu \
--cc=ebiederm@xmission.com \
--cc=felix.willgerodt@intel.com \
--cc=jhb@FreeBSD.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=matz@suse.de \
--cc=mpe@ellerman.id.au \
--cc=naveen.n.rao@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).