Date: Tue, 15 Aug 2017 13:44:41 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: "Rang, Anton" <Anton.Rang@dell.com> Cc: "freebsd-amd64@freebsd.org" <freebsd-amd64@freebsd.org> Subject: Re: XSAVE vs. XSAVEOPT in fpusave / fpu_kern_enter? Message-ID: <20170815104441.GG1700@kib.kiev.ua> In-Reply-To: <F21EDC44C64DB34B90AF485AC3CEDD4BBB339AEF@MX103CL02.corp.emc.com> References: <F21EDC44C64DB34B90AF485AC3CEDD4BBB339AEF@MX103CL02.corp.emc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 14, 2017 at 08:42:35PM +0000, Rang, Anton wrote: > Hi, > > While glancing at fpu_kern_enter, I noticed that fpusave() uses the > XSAVE instruction, but not XSAVEOPT. The instance in cpu_switch.S is > patched if XSAVEOPT is available, but should we also be able to use > XSAVEOPT in fpusave as well? I can't see any reason why not, but I'm > not 100% sure that the save area is set up properly in all cases. Yes, XSAVEOPT should be safe there. I have a WIP changes (for a long time) which emulate ifuncs in kernel. Then fpusave() becomes a function call through a pointer indirection, and avoids conditional, which makes adding XSAVEOPT variant free. But I postponed committing this change, and may postpone even more. If our system linker/external toolchain support gain a new linker that support ifunc, then it might be better to use real ifunc.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170815104441.GG1700>