[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: [PATCH] Fixing stack alignment in x86-64 Xen

  • To: "Andi Kleen" <ak@xxxxxx>
  • From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
  • Date: Wed, 18 May 2005 08:09:42 -0700
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 18 May 2005 15:09:14 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcVbssapFaXiKnTgQZyRFrdv1YtMfgABOd7g
  • Thread-topic: [PATCH] Fixing stack alignment in x86-64 Xen

Andi Kleen wrote:
> "Nakajima, Jun" <jun.nakajima@xxxxxxxxx> writes:
>> Long mode needs to align the stack on a 16-byte boundary. Recent
>> changes to Xen broke the requirement, and x86-64 XenLinux stopped
>> booting. The attached fixes the problem.
> Normally it should be only needed in user space for saving FP
> registers. The kernel and Xen which should not do this probably don't
> need it. 

Normally they don't care. The problem was that Xen set rsp0 in TSS on a
8-byte boundary and upon interrupts in Ring3 (XenLinux or user
processes) the processor started pushing registers (ss, rsp, rflags, ..,
rip) on the 16-byte boundary in Xen.  

The recent optimization reset_stack_and_jump() code needs to know the
exact address of the interrupt stack (because it resets %rsp), and
calculates it based on the value that Xen set (i.e. 8-byte boundary).
Since the processor forces the rsp0 on a 16-byte boundary (i.e. moves it
down by 8 bytes), Xen sees a wrong stack when returning from the


> Unless you save FP registers on the stack somewhere. Then I would
> rather fix that place only.
> At least the main linux kernel does not try to keep the stack
> always 16byte aligned. There is even a gcc option to turn it off
> and it saves some code (and probably stack) size.
> -Andi

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.