Date: Wed, 06 May 2009 09:22:21 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: =?ISO-8859-2?Q?Zahemszky_G=E1bor?= <Gabor@zahemszky.hu> Cc: freebsd-stable@freebsd.org, ia64@freebsd.org Subject: Re: IA64 7.2-RC2 in HP Integrity Virtual Machine Message-ID: <DB001D8D-A41C-477C-B8B4-C2C9973373A0@mac.com> In-Reply-To: <20090506163043.0aad883b@Picasso.Zahemszky.HU> References: <20090429063852.26767.qmail@mail.integrity.hu> <DA7392F4-F624-487D-950E-0EF016B5FF41@mac.com> <20090506163043.0aad883b@Picasso.Zahemszky.HU>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 6, 2009, at 7:30 AM, Zahemszky G=E1bor wrote: >> I believe there's a problem with mpt(4) that relates to >> its error recovery, or lack thereof. >> >> Can you send a backtrace so that we can confirm or de- >> bunk that statement? > > Hi! > > here it is. (sorry for the ESC-sequences, it is the virtual machine's > EFI boot loader) > > Attached. Ok. It's not mpt(4). It looks like it's the VM itself that's the problem. The page fault is the result of a clobbered r17. Looking at the registers and the source code, as well as the assembly I conclude that writes to the region registers (which are virtualized) cause a trap in the VM and the context is not properly saved or restored. I conclude this based on r16 being 1 (we've had 1 iteration of the loop on line 2220 in file sys/ia64/ia64/pmap.c (assuming r16 is not clobbered). This means we had at least 1 write to the region register. r17 is initialized to (&pm->pm_rid[0]) and since the load has a post-increment of 4, it "walks" the pm_rid array. It never has a value of 1. So, r17 must have been clobbered, because it's never assigned 1 in the program. So either the VM is buggy, or you need explicit support for the VM in the guest OS by design. FYI, --=20 Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DB001D8D-A41C-477C-B8B4-C2C9973373A0>