On Mon, 2018-01-08 at 22:13 +0100, Juerg Haefliger wrote:
>
> On 01/08/2018 09:39 PM, Ben Hutchings wrote:
> > On Mon, 2018-01-08 at 08:10 +0100, Juerg Haefliger wrote:
> > > Ben,
> > >
> > > On 01/08/2018 12:35 AM, Ben Hutchings wrote:
> > > > I have a backport of KPTI/KAISER to 3.16, based on Hugh Dickins's work
> > > > for 3.18, some upstream changes between 3.16 and 3.18, and other
> > > > patches that went into 4.4.75.
> > > >
> > > > I sent this out for review on the stable list after quite minimal
> > > > testing, but have done more since then. On bare metal (Sandy Bridge,
> > > > with pcid but not invpcid) it crashes at boot. In fact it
> > > > reboots without any panic message, suggesting a triple fault, as soon
> > > > as I apply the patch that turns on CR4.PCIDE, i.e. without KPTI itself.
> > >
> > > I've seen this as well with my 3.13 tree. As soon as PCID is set on the
> > > first (non-boot) CPU, the kernel reboots. Note that it seems to work
> > > fine with maxcpus=1.
> >
> > I see, this makes sense.
> >
> > > I've checked the other versions, your 3.2 doesn't have this issue and
> > > Hugh's 3.18 doesn't have it either. After some bisecting, I found that
> > > the problem was introduced in 3.15 by:
> > > cda846f101fb ('x86, realmode: read cr4 and EFER from kernel for 64-bit
> > > trampoline')
> > > and then later fixed again in 4.0 by:
> > > 375074cc736a ('x86: Clean up cr4 manipulation')
> >
> > Thanks! This plus obvious changes to the patches using
> > {clear,set}_in_cr4() gets me a kernel that boots on the SNB system.
>
> Do you have debs I could run some tests against?
[...]
Here you go:
https://www.decadent.org.uk/ben/tmp/linux-image-3.16.53-rc2_3.16.53-rc2-53_amd64.deb
Ben.
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
Attachment:
signature.asc
Description: This is a digitally signed message part