From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: guest crash in wrmsr_hypervisor_regs if hypercall page is paged out Date: Thu, 2 May 2013 16:43:01 +0200 Message-ID: <20130502144301.GA8910@aepfle.de> References: <20130430181917.GA13893@aepfle.de> <20130502112050.GJ65547@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20130502112050.GJ65547@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Thu, May 02, Tim Deegan wrote: > At 20:19 +0200 on 30 Apr (1367353157), Olaf Hering wrote: > > > > With current xen-unstable I see this guest crash if the gfn 169ff is > > paged out. The xenpaging -v output shows that 169ff is populated, but > > appearently wrmsr_hypervisor_regs does not like the resulting mfn?! > > Looks that way: > > > (XEN) HVM10: Allocated Xen hypercall page at 169ff000 > > (XEN) traps.c:654:d10 Bad GMFN 169ff (MFN 3e900000000) to MSR 40000000 > > That MFN looks like garbage, so I'm guessing that 'page' was null, i.e. > get_page_from_gfn() returned NULL. I guess you'll need to instrument it > up to figure out why. At least the GFN is a predictable constant which > should make it easier to add debugging printout for just this case. The GMFN has p2m_t p2m_ram_paged, so the mfn is -1. Its not clear to me, how should wrmsr_hypervisor_regs handle a paged gfn? I was under the impression that get_page_from_gfn would wait until the gfn is paged-in again. Olaf