Bug#660425: Possible bugg in linux-image-3.2.0-0.bpo.4-amd64 (resent)
Thanks Ben, not sure how I missed 660425 the first time around.
On Wed, 2013-01-23 at 14:50 +0000, Ben Hutchings wrote:
> On Tue, 2013-01-22 at 10:15 +0100, Mattias Eriksson wrote:
> > Hi!
> >
> > I have switched back to the current stable kernel in squeeze, 2.6.32-46, since I need the
> > machine to be up and running. And now it is just as stable as it was before.
> >
> > Even though I have never had any real issues using xen and VIA nano (64bit), the
> > CPU is officially not supported by xen, as far as I can see:
> >
> > (XEN) Domain heap initialised
> > (XEN) CPU: Vendor unknown, using generic init.
> > (XEN) CPU: Your system may be unstable.
> > (XEN) Processor #0 6:15 APIC version 20
> >
> > So, I think there are to many "uncertainties" for me to dig into this further.
> [...]
>
> Yes, there may be quirks and bugs in VIA/Centaur processors that Xen
> should handle (which I couldn't find any documentation about).
There was a bit of work done to support VIA stuff in, I think, the 4.2
release.
I think it is probably not relevant to this specific EFLAGS.AC issue,
although it may cause other problems of course.
> However: <http://bugs.debian.org/660425> is a report of an alignment check
> under Xen while running Linux 2.6.32, and Jonathan Nieder found (message
> #17) more reports of this - on Intel and AMD processors. In all these
> cases (and yours) the AC flag is shown as enabled, so alignment checks
> should be expected.
>
> The connection to Xen is this: the AC flag can be set by any program,
> but the processor ignores it when running code at the maximum privilege
> level. So normally the kernel is not affected, but under Xen it is
> running at lower privilege and therefore it is affected. Xen has to
> clear the AC flag whenever it switches from user mode to a (PV) guest
> kernel.
A bug of this type was fixed in the 4.0.0-rc9 timeframe, but that is
before the version of Xen being used here.
It's interesting that the kernel version appears to be a relevant
factor, but I expect it is simply exposing a hypervisor bug.
It seems that the new SMAP (Supervisor Mode Access Prevention) CPU
feature reuses the EFLAGS.AC bit, that might explain why we are seeing
this bit set in kernel mode with newer kernels. However it looks like
this was added in 3.7 and I can't see it backported in either the
kernel.org 3.2.y stable kernels or Debian's patch queue. SMEP is in 3.2
but I don't think that involves EFLAGS.AC.
It would be great if you could try the 3.2.0 kernel again with the
"nosmap" kernel option though.
> I don't think the guest kernel itself needs to be aware of this
> because there is never a direct transition from user mode to kernel
> mode.
Agreed, with a 64-bit PV kernel you always have to pass through the
hypervisor when transitioning from user to supervisor mode (which both
run in Ring 3 under Xen)
Ian.
--
Ian Campbell
Current Noise: Isis - Threshold Of Transformation
Be incomprehensible. If they can't understand, they can't disagree.
Reply to: