From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: HVM pvops failures (one more qemu-dm.strace obtained) Date: Tue, 03 Mar 2009 09:41:36 -0800 Message-ID: <49AD6BD0.8010006@goop.org> References: <49A33B62.1050303@goop.org> <80518.15147.qm@web56104.mail.re3.yahoo.com> <49A5B1D2.8050003@goop.org> <18854.32386.340159.586295@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andrew Lyon Cc: Ian Campbell , Boris Derzhavets , "xen-devel@lists.xensource.com" , Ian Jackson List-Id: xen-devel@lists.xenproject.org Andrew Lyon wrote: > On Thu, Feb 26, 2009 at 11:35 AM, Ian Jackson wrote: > >> Jeremy Fitzhardinge writes ("Re: [Xen-devel] HVM pvops failures (one more qemu-dm.strace obtained)"): >> >>> I was hoping Ian J would pop up and say "Its broken like this! Fix it >>> like this!". >>> >> Yes, when I have a moment I'll try it myself but I've been buried in >> the bowels of a nightmare USB emulation. Soon I'll know whether the >> latter works and thus whether I have any time to dig into pvops. >> >> Ian. >> >> > > Has anybody made any progress on the qemu-dm / hvm issue with pv_ops? > I spent most of yesterday going through the strace logs but I cannot > see why it fails as it does. > Thanks for looking into this. The crash is a SIGBUS in qemu, shortly after an mmap of /proc/xen/privcmd, which is a suspicious combination. The SIGBUS means we managed to create a mapping where the kernel thinks there are no backing pages (at least in part). It would be useful to know if any memory accesses to the privcmd mapping succeed, and what the offset of the failing one is. (Assuming the SIGBUS is related to a privcmd mapping at all.) I don't think privcmd mappings can be completely broken, because the qemu backend for pvfb works fine, and I assume that uses that path to map the framebuffer... Also, have you tried using stub domains? They should have no dependence on the dom0 kernel at all, so in theory they should work regardless. J