[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200408004111.3dd597f2a7c6172b4c71a9ba@kernel.org>
Date: Wed, 8 Apr 2020 00:41:11 +0900
From: Masami Hiramatsu <mhiramat@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Christian König <christian.koenig@....com>,
Jann Horn <jannh@...gle.com>,
Harry Wentland <harry.wentland@....com>,
Leo Li <sunpeng.li@....com>, amd-gfx@...ts.freedesktop.org,
Alex Deucher <alexander.deucher@....com>,
"David (ChunMing) Zhou" <David1.Zhou@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
the arch/x86 maintainers <x86@...nel.org>,
kernel list <linux-kernel@...r.kernel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Andy Lutomirski <luto@...nel.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: AMD DC graphics display code enables -mhard-float, -msse,
-msse2 without any visible FPU state protection
On Tue, 7 Apr 2020 13:15:35 +0200
Peter Zijlstra <peterz@...radead.org> wrote:
> On Tue, Apr 07, 2020 at 06:50:08PM +0900, Masami Hiramatsu wrote:
> > On Mon, 6 Apr 2020 12:21:07 +0200
> > Peter Zijlstra <peterz@...radead.org> wrote:
>
> > > arch/x86/mm/extable.o: warning: objtool: ex_handler_fprestore()+0x8b: fpu_safe hint not an FPU instruction
> > > 008b 36b: 48 0f ae 0d 00 00 00 fxrstor64 0x0(%rip) # 373 <ex_handler_fprestore+0x93>
> > >
> > > arch/x86/kvm/x86.o: warning: objtool: kvm_load_guest_fpu.isra.0()+0x1fa: fpu_safe hint not an FPU instruction
> > > 01fa 1d2fa: 48 0f ae 4b 40 fxrstor64 0x40(%rbx)
> >
> > Ah, fxstor will not chang the FPU/MMX/SSE regs but just store it on memory.
> > OK, I'll remove it from the list.
>
> Yeah, I don't much care if its in or out, but the way I was reading that
> patch it _should_ be in, but then it doesn't seem to recognise it.
Oops, I misread. OK. I fixed the issue.
>
> > > Also, all the VMX bits seems to qualify as FPU (I can't remember seeing
> > > that previously):
> >
> > Oops, let me check it.
>
> I just send you another patch that could do with insn_is_vmx()
> (sorry!!!)
Hmm, it is hard to find out the vmx insns. Maybe we need to clarify it by
opcode pattern. (like "VM.*")
Thank you,
--
Masami Hiramatsu <mhiramat@...nel.org>
Powered by blists - more mailing lists