From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Richard W.M. Jones" Subject: Re: kvm [2087]: load/store instruction decoding not implemented Date: Tue, 24 Feb 2015 14:36:08 +0000 Message-ID: <20150224143608.GO11603@redhat.com> References: <20150224115935.GA26241@redhat.com> <20150224122925.GL11603@redhat.com> <20150224124710.GB21364@cbox> <54EC78D1.3030703@arm.com> <20150224134533.GM11603@redhat.com> <54EC8654.1060905@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id BF5C146756 for ; Tue, 24 Feb 2015 09:30:35 -0500 (EST) Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Suiu3Lj5uDoz for ; Tue, 24 Feb 2015 09:30:33 -0500 (EST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 21A3C4670E for ; Tue, 24 Feb 2015 09:30:32 -0500 (EST) Content-Disposition: inline In-Reply-To: <54EC8654.1060905@arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu To: Marc Zyngier Cc: "kvmarm@lists.cs.columbia.edu" List-Id: kvmarm@lists.cs.columbia.edu On Tue, Feb 24, 2015 at 02:10:28PM +0000, Marc Zyngier wrote: > On 24/02/15 13:45, Richard W.M. Jones wrote: > > On Tue, Feb 24, 2015 at 01:12:49PM +0000, Marc Zyngier wrote: > >> Here's my theory: userspace is accessing something it should never > >> access (outside of RAM, basically), and doing so via a kernel interface. > >> > >> Is this process accessing /dev/mem by any chance? dmidecode anyone? > > > > Not as far as I know. The userspace process is inserting modules. > > > > Here is the userspace function which is most likely to be running: > > > > https://github.com/libguestfs/supermin/blob/master/src/init.c#L292 > > Hmmm. That seems quite inoffensive indeed... > > > Unfortunately because of lack of a full stack trace, I can't be sure > > exactly what system call is failing, but I'll probably add more debug > > to the userspace program later. > > > > BTW this worked fine in 3.19. It's started failing in 3.20/4.0. It > > also works fine on x86. > > Any chance you could find out whether that's a host or guest regression? Here is a summary of the test combinations that I have run: guest kernel host kernel result -------------------------------------------------------- 3.19.0-0.rc7 3.19.0-0.rc7 no bug seen 3.20.0-0.rc0 3.19.0-0.rc7 bug seen 3.19.0-0.rc7 4.0.0-0.rc1 no bug seen 4.0.0-0.rc1 4.0.0-0.rc1 bug seen So a guest regression, I think? It's also possible the bug existed in old kernels but was masked somehow, eg. different memory layout. I can probably bisect this given time, but I'm going to try putting some debug into the userspace process to find out which system call fails first. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW