On 28/02/17 15:27, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
> <pure.logic@xxxxxxxxxxxxxxxxx> wrote:
>> On 28/02/17 13:36, Andy Shevchenko wrote:
>>> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
>>> <andy.shevchenko@xxxxxxxxx> wrote:
>>>> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
>>>> <ard.biesheuvel@xxxxxxxxxx> wrote:
>>>>> On 28 February 2017 at 12:29, Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote:
>>>>>> On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
>>>>
>>>>> As I said before, I'd be ok with it if we select it compile time,
>>>>> i.e., no runtime logic that infers whether we are running on such a
>>>>> system or not, and no carrying both implementations in all kernels
>>>>> that have capsule loading built in.
>>>>
>>>> Actually it most likely that Quark kernel (kernel compiled to be run
>>>> on Quark) will be ever used on the rest of (modern) x86 since it's
>>>> 486+ architecture (kernel has specific option for it, 586TSC).
>>>
>>> + it's UP only!
>>>
>>>> So, we might just be dependent or chosen by Quark.
>>>
>>
>> Still though the current ia32 kernel runs on Quark and all other ia32
>> systems.
>
> How come? Quark has a silicon bug (SMP kernel might oops) and it is
> not even i586!
sorry if this is a bit long in advance...
You mean a lock prefixed pagefault.
For reference Quark should be considered CONFIG_M586TSC=y (or better)
i.e. it's 586 ISA with a TSC added on.
I've been meaning to do a write up about this, since I've spent some
time with a debugger doing an analysis of the fault. Basically any
operation that is lock-prefixed that also page-faults pushes the address
of the _previous_ instruction (not the instruction that faulted) onto
the PF# stack. Which sucks.
Obviously then when you IRET you will execute the previous instruction
again - on return to user-space - as opposed to the instruction you
faulted on.
So it's nothing to do with SMP per se, except that the lock prefix was
added to drive the #lock signal on future SMP versions of the part (that
never happened). We discussed this @ the time Dave Jones did
commit d4e1a0af1d3a88cdfc8c954d3005eb8745ec518d
Author: Dave Jones <davej@xxxxxxxxxx>
Date: Tue Oct 28 13:57:53 2014 -0400
x86: Don't enable F00F workaround on Intel Quark processors
... and we agreed to have a good look at lock prefixed instructions in
the kernel. On !SMP builds there is (or was at the time anyway) alot of
LOCK_PREFIX looking like this
#ifdef CONFIG_SMP
#define LOCK_PREFIX_HERE \
".pushsection .smp_locks,\"a\"\n" \
".balign 4\n" \
".long 671f - .\n" /* offset */ \
".popsection\n" \
"671:"
#define LOCK_PREFIX LOCK_PREFIX_HERE "\n\tlock; "
#else /* ! CONFIG_SMP */
#define LOCK_PREFIX_HERE ""
#define LOCK_PREFIX ""
#endif
Which meant that !SMP was safe. It was probably overkill though because
kernel code shouldn't PF anyway.
User-space is another story.
This image faults reliably in rpc-stad and sshd - because like I say -
lock-prefixed page faults push the previous (not the current)
instruction onto the pagefault stack.
https://sourceforge.net/projects/galileodebian/
anyway...
!SMP ia32 builds should be fine and we have never actually seen _kernel_
code die on SMP builds ... presumably (demonstrably) because lock
prefixed operations in the kernel don't PF#.
>> It would be a pity/shame to make this feature dependent on
>> compiling a Quark specific kernel, after all its only a header on a
>> capsule as opposed to a large hardware-level architectural divergence.
>>
>
>> I'd still like us to try for a low-fat hook that would a big fat ia32
>> kernel just work without having to force a user compile up a
>> Quark-specific kernel.
>
> Can you elaborate how to run i686 kernel (which is default for x86
> 32-bit AFAIK) on Quark?
A kernel compiled like this
make menuconfig ARCH=i386
make bzImage -j 8
will run just fine on Quark x1000 I do it regularly. CPUID ought to (and
does) inform the runtime kernel of what to do re: MSRs etc.
We won't execute xmm/mmx, we won't touch 686 specific MSRs etc, etc.
--
bod
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
