From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Tracebacks from dom0 pvops changeset 2342 Date: Fri, 20 Feb 2009 14:34:00 -0800 Message-ID: <499F2FD8.8000109@goop.org> References: <498F896A.5070505@goop.org> <499074EF.7010401@goop.org> <499085DF.4070509@goop.org> <4990B300.9060302@goop.org> <0B53E02A2965CE4F9ADB38B34501A3A16D8517B1@orsmsx505.amr.corp.intel.com> <4990D580.3020801@goop.org> <0B53E02A2965CE4F9ADB38B34501A3A16D8EE057@orsmsx505.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <0B53E02A2965CE4F9ADB38B34501A3A16D8EE057@orsmsx505.amr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Nakajima, Jun" Cc: "xen-devel@lists.xensource.com" , Keir Fraser , M A Young List-Id: xen-devel@lists.xenproject.org Nakajima, Jun wrote: >>> Looks like it's the mod_l1_entry() called by do_update_va_mapping(), >>> and the guest stack shows (by vcpu_show_execution_state() that I >>> added) it's going back to xen_mc_flush(). As long as I ignore the >>> MEM_LOG message, it boots up to the login prompt. >>> >>> >> Odd. What's the backtrace beyond that? >> > > This is coming from remap_pte_range() in dom0, which calls set_pte_at(), calling MULTI_update_va_mapping(). Looks like pteval is 0xfffff7fffffff237. As far as I checked the code, the prot has the NX bit :-), and pfn looked normal there: > pte_mkspecial(pfn_pte(pfn, prot) > Hm, this is (I guess) intending to map machine physical memory. If it doesn't have _PAGE_IOMAP set in the pte, then we'll try to do a pfn->mfn conversion, which won't work well if the pte doesn't have a pfn to start with. I've just been trying to get drm doing something sensible, so I've made some fixes in this area. Have a look at today's lot of xen/dom0/hackery changesets. >>> One thing that puzzles me is that MC_DEBUG is 1 in multicalls.c, but >>> I don't see any complaints from dom0. Is the following MC_DEBUG working? >>> Or I may be looking at a wrong stack. >>> >>> >> Yes, I've noticed that sometimes multicalls seem not to report >> detectable errors. I haven't looked into see what's really going on. >> >> J >> > > I confirmed that the multicalls were failing in Xen (but the result was not propagated to the caller). > Keir, do you know anything about this? It seems that multicalls are not reliably reporting errors. J