[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878rz9gdbb.ffs@tglx>
Date: Mon, 04 Oct 2021 14:54:48 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: "Bae, Chang Seok" <chang.seok.bae@...el.com>
Cc: "bp@...e.de" <bp@...e.de>, "Lutomirski, Andy" <luto@...nel.org>,
"mingo@...nel.org" <mingo@...nel.org>,
"x86@...nel.org" <x86@...nel.org>,
"Brown, Len" <len.brown@...el.com>,
"lenb@...nel.org" <lenb@...nel.org>,
"Hansen, Dave" <dave.hansen@...el.com>,
"Macieira, Thiago" <thiago.macieira@...el.com>,
"Liu, Jing2" <jing2.liu@...el.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH v10 04/28] x86/fpu/xstate: Modify address finders to
handle both static and dynamic buffers
On Sun, Oct 03 2021 at 22:35, Chang Seok Bae wrote:
> On Oct 1, 2021, at 06:15, Thomas Gleixner <tglx@...utronix.de> wrote:
>
> Okay, a NULL pointer is odd and it as an argument should be avoided. Defining
> a separate struct fpu for the initial state can make every function expect a
> valid struct fpu pointer.
>
> I think that the patch set will have such order (once [1] is dropped out) of,
> - patch1 (new): a cleanup patch for fpstate_init_xstate() in patch1
> - patch2 (new): the above init_fpu goes into this, and
> - patch3-5: changes arguments to fpu,
So actually I sat down over the weekend and looked at that again. Adding this
to struct fpu is wrong. The size and features information belongs into
something like this:
struct fpstate {
unsigned int size;
u64 xfeatures;
union fpregs_state regs;
};
Why? Simply because fpstate is the container for the dynamically sized
regs and that's where it semantically belongs.
While staring at that I just started to cleanup stuff all over the place
to make the integration of this simpler.
The patches are completely untested and have no changelogs yet, but if
you want a preview, I've uploaded a patch series to:
https://tglx.de/~tglx/patches.tar
I'm still staring at some of the dynamic feature integrations, but this
is roughly where this should be heading.
Thanks,
tglx
Powered by blists - more mailing lists