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

[Xen-ia64-devel] [PATCH] Fix weird dom0 behavior due to incorrent kr emulation


  • To: <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Tue, 1 Nov 2005 22:30:46 +0800
  • Delivery-date: Tue, 01 Nov 2005 14:27:48 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcXe8NifnwSTbkKkQrq0N0tO3uFQXw==
  • Thread-topic: [PATCH] Fix weird dom0 behavior due to incorrent kr emulation

Then, this is another easy-fix but hard-won issue which spent me most of
the day to track down.

The phenomenon is very weird. Dom0 can run pretty well itself, but once
creating another domain, I saw dom0 falling into nested fault or panic
being unable to handle kernel paging request. The worst is, dom0 even
used user stack like 0x60000ffff... in kernel space. That made me
confused why dom0 doesn't switch stack though I confirmed vIIP actually
from user space.

Finally the cause is intuitive as the attached patch. All writes to
KR0-7 by guest are pushed to same place (vkr0) in shared page including
important current pointer. Because domain owns physical KRs, those
writes will also be updated into physical KRs. If there's no domain
switch, dom0 always read from physical KRs which contain right values.
Only after switching back to dom0, last KR patch will try to reload
physical KRs from shared page and however that memory area contains
incorrect values. So later execution flow went crazy by checking
incorrect current pointer.

Signed-off-by Kevin Tian <Kevin.tian@xxxxxxxxx>

Thanks,
Kevin

Attachment: fix_set_kr
Description: fix_set_kr

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel

 


Rackspace

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