Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1207369 > unrolled thread
| Started by | Ingo Molnar <mingo@kernel.org> |
|---|---|
| First post | 2015-08-14 09:20 +0200 |
| Last post | 2015-08-18 10:00 +0200 |
| Articles | 13 on this page of 33 — 6 participants |
Back to article view | Back to linux.kernel
[GIT PULL] x86 fixes Ingo Molnar <mingo@kernel.org> - 2015-08-14 09:20 +0200
Re: [GIT PULL] x86 fixes Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 20:30 +0200
Re: [GIT PULL] x86 fixes Andy Lutomirski <luto@amacapital.net> - 2015-08-14 20:50 +0200
Re: [GIT PULL] x86 fixes Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 21:00 +0200
Re: [GIT PULL] x86 fixes Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 21:10 +0200
Re: [GIT PULL] x86 fixes Andy Lutomirski <luto@amacapital.net> - 2015-08-14 21:20 +0200
Re: [GIT PULL] x86 fixes Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 21:40 +0200
Re: [GIT PULL] x86 fixes Andy Lutomirski <luto@amacapital.net> - 2015-08-14 21:20 +0200
Re: [GIT PULL] x86 fixes Ingo Molnar <mingo@kernel.org> - 2015-08-17 10:10 +0200
Re: [GIT PULL] x86 fixes Denys Vlasenko <dvlasenk@redhat.com> - 2015-08-17 13:00 +0200
Re: [GIT PULL] x86 fixes Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-17 19:00 +0200
Re: [GIT PULL] x86 fixes Ingo Molnar <mingo@kernel.org> - 2015-08-18 10:00 +0200
Re: [GIT PULL] x86 fixes Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-17 18:50 +0200
Re: [GIT PULL] x86 fixes "H. Peter Anvin" <hpa@zytor.com> - 2015-08-17 19:00 +0200
Re: [GIT PULL] x86 fixes Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-17 19:20 +0200
Re: [GIT PULL] x86 fixes "H. Peter Anvin" <hpa@zytor.com> - 2015-08-18 00:20 +0200
Re: [GIT PULL] x86 fixes Ingo Molnar <mingo@kernel.org> - 2015-08-19 08:00 +0200
Re: [GIT PULL] x86 fixes Ingo Molnar <mingo@kernel.org> - 2015-08-19 08:20 +0200
Re: [GIT PULL] x86 fixes Ingo Molnar <mingo@kernel.org> - 2015-08-19 09:00 +0200
Re: [GIT PULL] x86 fixes "H. Peter Anvin" <hpa@zytor.com> - 2015-08-19 12:10 +0200
Re: [GIT PULL] x86 fixes Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-20 00:40 +0200
Re: [GIT PULL] x86 fixes "H. Peter Anvin" <hpa@zytor.com> - 2015-08-20 09:00 +0200
Re: [GIT PULL] x86 fixes "H. Peter Anvin" <hpa@zytor.com> - 2015-08-20 00:00 +0200
Re: [GIT PULL] x86 fixes Denys Vlasenko <dvlasenk@redhat.com> - 2015-08-21 12:20 +0200
Re: [GIT PULL] x86 fixes Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2015-08-18 01:50 +0200
Re: [GIT PULL] x86 fixes "H. Peter Anvin" <hpa@zytor.com> - 2015-08-17 23:10 +0200
Re: [GIT PULL] x86 fixes Andy Lutomirski <luto@amacapital.net> - 2015-08-18 02:00 +0200
Re: [GIT PULL] x86 fixes "H. Peter Anvin" <hpa@zytor.com> - 2015-08-18 02:10 +0200
Re: [GIT PULL] x86 fixes "H. Peter Anvin" <hpa@zytor.com> - 2015-08-18 02:10 +0200
Re: [GIT PULL] x86 fixes Andy Lutomirski <luto@amacapital.net> - 2015-08-18 02:20 +0200
Re: [GIT PULL] x86 fixes "H. Peter Anvin" <hpa@zytor.com> - 2015-08-18 08:00 +0200
Re: [GIT PULL] x86 fixes "H. Peter Anvin" <hpa@zytor.com> - 2015-08-18 08:10 +0200
Re: [GIT PULL] x86 fixes Ingo Molnar <mingo@kernel.org> - 2015-08-18 10:00 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2015-08-20 00:40 +0200 |
| Message-ID | <pZkbv-2Gm-7@gated-at.bofh.it> |
| In reply to | #1209759 |
On Wed, Aug 19, 2015 at 3:00 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> And I bet if CPUID actually reported the right thing it probably would work
> okay. As I said, I tested this under Qemu which reported an accurate (lack
> of) CPUID for a 486SX.
While I agree that cpuid is a problem for FPU emulation on modern
CPU's, if this is due to "fucomip" then I think it's just that modern
distributions (and not-so-modern ones, for that matter) are compiled
with i686 support, so gcc just generates fucomip directly. So it's
just "plain FPU" code (no mmx, nothing like that), but it still fails.
The "set regular integer flags instructions" versions of floating
point compares are some of the bigger improvements to the legacy i87
instruction set, because the sequences to do FP compares without them
are just insane. I forget the details, but it's something like "store
status word to ax, then use sahf to get it into the flags register".
Crazy crazy crap. So it's no wonder that gcc wants to use a i686-only
instruction even for just regular FP code if at all possible.
I suspect it shouldn't be that hard to add f[u]compi[p] support to the
emulator.
But I also expect that most modern distributions are likely fairly
eager to use mmx etc, which sounds like a major pain to emulate.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2015-08-20 09:00 +0200 |
| Message-ID | <pZrZo-5EL-15@gated-at.bofh.it> |
| In reply to | #1210059 |
Yes, and MMX, SSE et al didn't have the envision trap support, so you would have to do a full decide and emulation inside the #UD handler. However, the trap overhead for a lot of those instructions is extreme, as compared to the rather heavyweight x87 instructions (in terms of the ratio between the trap overhead and the actual emulation code.) On August 19, 2015 3:33:50 PM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote: >On Wed, Aug 19, 2015 at 3:00 AM, H. Peter Anvin <hpa@zytor.com> wrote: >> >> And I bet if CPUID actually reported the right thing it probably >would work >> okay. As I said, I tested this under Qemu which reported an accurate >(lack >> of) CPUID for a 486SX. > >While I agree that cpuid is a problem for FPU emulation on modern >CPU's, if this is due to "fucomip" then I think it's just that modern >distributions (and not-so-modern ones, for that matter) are compiled >with i686 support, so gcc just generates fucomip directly. So it's >just "plain FPU" code (no mmx, nothing like that), but it still fails. > >The "set regular integer flags instructions" versions of floating >point compares are some of the bigger improvements to the legacy i87 >instruction set, because the sequences to do FP compares without them >are just insane. I forget the details, but it's something like "store >status word to ax, then use sahf to get it into the flags register". >Crazy crazy crap. So it's no wonder that gcc wants to use a i686-only >instruction even for just regular FP code if at all possible. > >I suspect it shouldn't be that hard to add f[u]compi[p] support to the >emulator. > >But I also expect that most modern distributions are likely fairly >eager to use mmx etc, which sounds like a major pain to emulate. > > Linus -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2015-08-20 00:00 +0200 |
| Message-ID | <pZjyP-1GO-49@gated-at.bofh.it> |
| In reply to | #1209668 |
On 08/18/2015 11:50 PM, Ingo Molnar wrote: > > So I take back my claim, math-emu works. If math-emu grew support for some P6 era > FPU instructions it might even boot up generic distros without too much trouble. > For the record, I used a RedHat 4.1 (not Fedora or RHEL!) userspace. https://plus.google.com/107672941537404681483/posts/2GYcSm5injN -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Denys Vlasenko <dvlasenk@redhat.com> |
|---|---|
| Date | 2015-08-21 12:20 +0200 |
| Message-ID | <pZRAw-DT-71@gated-at.bofh.it> |
| In reply to | #1209668 |
On 08/19/2015 08:50 AM, Ingo Molnar wrote: > I get some instances of: > > /etc/rc3.d/S99local: line 26: 1626 Illegal instruction > > due to user-space presuming modern FPU capabilities: > > Program received signal SIGILL, Illegal instruction. > 0xb76be371 in RAND_SSLeay () from /lib/libcrypto.so.6 > > 0xb76be371 <RAND_SSLeay+1297>: fucomip %st(1),%st > > FUCOMPIP is a P6+ FPU instruction. I have a patch which adds support for emulating it. Will post now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Bryan O'Donoghue <pure.logic@nexus-software.ie> |
|---|---|
| Date | 2015-08-18 01:50 +0200 |
| Message-ID | <pYCka-5wZ-35@gated-at.bofh.it> |
| In reply to | #1208727 |
On 17/08/15 18:17, Linus Torvalds wrote: > On Mon, Aug 17, 2015 at 9:58 AM, H. Peter Anvin <hpa@zytor.com> wrote: >> That is not true. It *does* work, and I have tested it fairly recently. > > Ok, so it's not too badly broken. Good. > > Also, while it's been a long time since we needed FPU emulation on the > i486sx, I don't recall the details of any of the (much more modern) > IoT small cores. I *think* the base platforms are all at a Pentium > level (ie not just FPU, but MMX), but maybe there's some reason to > keep FP emulation alive for some platforms. > > Linus Quark is pentium ISA - it has tsc, apic, fpu but, not mmx. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2015-08-17 23:10 +0200 |
| Message-ID | <pYzPj-27r-11@gated-at.bofh.it> |
| In reply to | #1208457 |
Let me see when I last treated this... but I thought it was much more recently than that.
On August 17, 2015 1:01:43 AM PDT, Ingo Molnar <mingo@kernel.org> wrote:
>
>(Sorry about the late reply, wasn't around on the weekend.)
>
>* Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> Now that said, I doubt anybody cares. Since we don't support the
>original 80386,
>> the only way to ever trigger FP emulation is by having a 486SX or
>possibly a
>> couple of even rarer clone chips. [...]
>
>Yeah. So when I re-wrote the FPU code I tried to test math-emu by
>booting with
>'no387': it turned out that ever since the XSAVE code got merged
>upstream,
>math-emu oopsed reliably during bootup with a NULL reference, because
>it wasn't
>updated to the dynamic allocation logic in:
>
> 61c4628b5386 ("x86, fpu: split FPU state from task struct - v5")
>
>That was 6 years ago, so anything v2.6.26 and later probably has 100%
>non-working
>math-emu.
>
>So when I re-introduced static allocations math-emu started working
>again, to a
>limited degree: on a modern distro, trying to boot /bin/bash I got a
>prompt, but
>various programs would segfault. I did not investigate it any deeper, I
>suppose
>the FPU emulation does not go far enough for modern user-space, or
>maybe it has
>more bugs.
>
>So in reality nobody has cared about x86 math-emu in the last 6 years
>and we can
>probably remove it for good. I kept it for nostalgic reasons, but I
>guess using
>v2.4 kernels ought to be enough for those with nostalgia?
>
>> [...] So it's not like the fact that the code is completely wrong and
>crap
>> actually *matters*, but I still refuse to pull stuff that seems to be
>so
>> completely screwed up.
>
>That's true, my bad for merging it!
>
>Any objections against removing all of math-emu in v4.3? This would
>simplify the
>FPU code in various places beyond math-emu/.
>
>Thanks,
>
> Ingo
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-18 02:00 +0200 |
| Message-ID | <pYCtP-5KG-11@gated-at.bofh.it> |
| In reply to | #1208457 |
On Mon, Aug 17, 2015 at 1:01 AM, Ingo Molnar <mingo@kernel.org> wrote: > So when I re-introduced static allocations math-emu started working again, to a > limited degree: on a modern distro, trying to boot /bin/bash I got a prompt, but > various programs would segfault. I did not investigate it any deeper, I suppose > the FPU emulation does not go far enough for modern user-space, or maybe it has > more bugs. > Were you testing with just no387 or did you run a VM with SSE2 and such turned off? There's a *lot* of userspace that incorrectly checks for instructions without checking for the state support. I've filed bugs against libgcc for this and they're still not fixed IIRC. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2015-08-18 02:10 +0200 |
| Message-ID | <pYCDv-6cc-7@gated-at.bofh.it> |
| In reply to | #1208967 |
I ran a hacked Qemu with FPU off. On August 17, 2015 4:59:18 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote: >On Mon, Aug 17, 2015 at 1:01 AM, Ingo Molnar <mingo@kernel.org> wrote: >> So when I re-introduced static allocations math-emu started working >again, to a >> limited degree: on a modern distro, trying to boot /bin/bash I got a >prompt, but >> various programs would segfault. I did not investigate it any deeper, >I suppose >> the FPU emulation does not go far enough for modern user-space, or >maybe it has >> more bugs. >> > >Were you testing with just no387 or did you run a VM with SSE2 and >such turned off? > >There's a *lot* of userspace that incorrectly checks for instructions >without checking for the state support. I've filed bugs against >libgcc for this and they're still not fixed IIRC. > >--Andy -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2015-08-18 02:10 +0200 |
| Message-ID | <pYCDv-6cc-11@gated-at.bofh.it> |
| In reply to | #1208967 |
User space does not need to treat for FPU instructions, except for performance reasons, because the kernel emulates the full x87 FPU. So it is localized to the kernel. On August 17, 2015 4:59:18 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote: >On Mon, Aug 17, 2015 at 1:01 AM, Ingo Molnar <mingo@kernel.org> wrote: >> So when I re-introduced static allocations math-emu started working >again, to a >> limited degree: on a modern distro, trying to boot /bin/bash I got a >prompt, but >> various programs would segfault. I did not investigate it any deeper, >I suppose >> the FPU emulation does not go far enough for modern user-space, or >maybe it has >> more bugs. >> > >Were you testing with just no387 or did you run a VM with SSE2 and >such turned off? > >There's a *lot* of userspace that incorrectly checks for instructions >without checking for the state support. I've filed bugs against >libgcc for this and they're still not fixed IIRC. > >--Andy -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-18 02:20 +0200 |
| Message-ID | <pYCNb-6pb-13@gated-at.bofh.it> |
| In reply to | #1208973 |
On Mon, Aug 17, 2015 at 5:06 PM, H. Peter Anvin <hpa@zytor.com> wrote: > User space does not need to treat for FPU instructions, except for performance reasons, because the kernel emulates the full x87 FPU. So it is localized to the kernel. But user space needs to avoid SSE2 and such, I suspect. In general, I'd be surprised if things work well if we emulate the FPU (and set CR0.em? I haven't checked out Linux's FPU emulation works) if user code sees fancy instruction sets exposed and possibly even OSXSAVE. None of this matters except for testing, since it's very unlikely that any CPU exists that supports XSAVE, XMM, SSE2, etc but uses emulated x87. But if we emulate such a beast, things could break, and I bet that's what Ingo's seeing. (Also, lots of distros target "i686" these days, and that might cause its own set of problems.) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2015-08-18 08:00 +0200 |
| Message-ID | <pYI6d-5Co-1@gated-at.bofh.it> |
| In reply to | #1208978 |
I used a very old userspace, and embedded systems are much more likely to use uclibc than glibc. However, if they try to use SSE without checking they will break on a hell of a lot more hardware. On August 17, 2015 5:19:10 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote: >On Mon, Aug 17, 2015 at 5:06 PM, H. Peter Anvin <hpa@zytor.com> wrote: >> User space does not need to treat for FPU instructions, except for >performance reasons, because the kernel emulates the full x87 FPU. So >it is localized to the kernel. > >But user space needs to avoid SSE2 and such, I suspect. In general, >I'd be surprised if things work well if we emulate the FPU (and set >CR0.em? I haven't checked out Linux's FPU emulation works) if user >code sees fancy instruction sets exposed and possibly even OSXSAVE. > >None of this matters except for testing, since it's very unlikely that >any CPU exists that supports XSAVE, XMM, SSE2, etc but uses emulated >x87. But if we emulate such a beast, things could break, and I bet >that's what Ingo's seeing. (Also, lots of distros target "i686" these >days, and that might cause its own set of problems.) > >--Andy -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2015-08-18 08:10 +0200 |
| Message-ID | <pYIfU-631-25@gated-at.bofh.it> |
| In reply to | #1208978 |
I should make it clear: I was using a 486SX model in Qemu. On August 17, 2015 5:19:10 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote: >On Mon, Aug 17, 2015 at 5:06 PM, H. Peter Anvin <hpa@zytor.com> wrote: >> User space does not need to treat for FPU instructions, except for >performance reasons, because the kernel emulates the full x87 FPU. So >it is localized to the kernel. > >But user space needs to avoid SSE2 and such, I suspect. In general, >I'd be surprised if things work well if we emulate the FPU (and set >CR0.em? I haven't checked out Linux's FPU emulation works) if user >code sees fancy instruction sets exposed and possibly even OSXSAVE. > >None of this matters except for testing, since it's very unlikely that >any CPU exists that supports XSAVE, XMM, SSE2, etc but uses emulated >x87. But if we emulate such a beast, things could break, and I bet >that's what Ingo's seeing. (Also, lots of distros target "i686" these >days, and that might cause its own set of problems.) > >--Andy -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Date | 2015-08-18 10:00 +0200 |
| Message-ID | <pYJYm-8k5-15@gated-at.bofh.it> |
| In reply to | #1208967 |
* Andy Lutomirski <luto@amacapital.net> wrote: > On Mon, Aug 17, 2015 at 1:01 AM, Ingo Molnar <mingo@kernel.org> wrote: > > > So when I re-introduced static allocations math-emu started working again, to > > a limited degree: on a modern distro, trying to boot /bin/bash I got a prompt, > > but various programs would segfault. I did not investigate it any deeper, I > > suppose the FPU emulation does not go far enough for modern user-space, or > > maybe it has more bugs. > > Were you testing with just no387 or did you run a VM with SSE2 and such turned > off? > > There's a *lot* of userspace that incorrectly checks for instructions without > checking for the state support. I've filed bugs against libgcc for this and > they're still not fixed IIRC. I tested relatively ancient user-space, 2007 era Fedora Core 6 - but I didn't check whether it's truly SSE-less (it probably isn't). Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web