Re: use of MI "pcu" code for x86 FPU, allocate FPU context dynamically

[David Laight <david%l8s.co.uk@localhost>]

On Mon, Sep 09, 2013 at 12:26:59PM +0200, Matthias Drochner wrote:
> 
> Hi -
> 
> The x86 FPU/NPX code isn't quite fit for the needs of modern processors.
> There is no support for AVX and later multimedia/vector extensions yet,
> and it is impossible to use the FPU in the kernel, which would be
> useful for IPSEC (the AES instructions, SHA is announced).
> 
> This could certainly be fixed within the MD i386/amd64 code (there is
> not much shared currently), adding even mode MD code.

I looked a bit at AVX support and was dismayed at the unnecessary
differences between i386 and amd64.
It seems best to merge those to some extent - if only the .h files
for common structures - before embarking on any more changes.

I did spot some difficulties though:

1) i386 core dumps seem to only have i387 support.
   (The amd64 core dumps do at least contain the SSE2 registers.)
   I also think that the code that maps the 'newer' FP formats to
   the i387 format is broken. I read in one of the Intel docs that
   the i387 regs are saved/flagged relative to the stack top.

2) The whole way that core dumps are generated needs to be changed
   in order to not need on-stack copies of the FP state.
   I think there are currently two copies, dump the AVX registers
   and you'll blow the kernel stack.

3) gdb register layouts.

Also make sure that anything you do is compatible with the optimised
FP resgister saving of the newer intel cpus.
I didn't quite grok all of it, but I think it is carefully arranged
so that the FP save instruction knows which registers need saving
(or restoring) saving all the memory cycles when no regsisters
in one of the blocks has been modified.


        David

-- 
David Laight: david%l8s.co.uk@localhost