From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54894) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6hls-0005WD-1B for qemu-devel@nongnu.org; Tue, 15 Nov 2016 12:43:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6hlo-0000ul-Tw for qemu-devel@nongnu.org; Tue, 15 Nov 2016 12:43:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54384) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c6hlo-0000uO-Mi for qemu-devel@nongnu.org; Tue, 15 Nov 2016 12:43:44 -0500 Date: Tue, 15 Nov 2016 17:43:39 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20161115174338.GI2038@work-vm> References: <20161115110956.5393749d@bahia> <20161115155642.345d1863@bahia> <44b410d5-907c-cff9-0366-a86718bb0352@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44b410d5-907c-cff9-0366-a86718bb0352@redhat.com> Subject: Re: [Qemu-devel] QEMU postcopy-test failing on ppc64 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth Cc: Stefan Hajnoczi , Greg Kurz , Laurent Vivier , Andrea Arcangeli , qemu-devel * Thomas Huth (thuth@redhat.com) wrote: > On 15.11.2016 16:18, Stefan Hajnoczi wrote: > > On Tue, Nov 15, 2016 at 2:56 PM, Greg Kurz wrote: > >> On Tue, 15 Nov 2016 11:14:57 +0000 > >> Stefan Hajnoczi wrote: > >> > >>> On Tue, Nov 15, 2016 at 10:09 AM, Greg Kurz wrote: > >>>> On Tue, 15 Nov 2016 10:53:35 +0100 > >>>> Laurent Vivier wrote: > >>>> > >>>>> On 14/11/2016 21:52, Stefan Hajnoczi wrote: > >>>>>> I hit a failure running "make check" on ppc64 for the first time. Ideas? > >>>>>> > >>>>>> Stefan > >>>>>> > >>>>>> commit 682df581c65ed2c1b9e77093e332214ecaa1ee93 > >>>>>> > >>>>>> GTESTER check-qtest-ppc64 > >>>>>> Memory content inconsistency at 5af4000 first_byte = 1b last_byte = 1a > >>>>>> current = 7c hit_edge = 1 > >>>>>> Memory content inconsistency at 5af5000 first_byte = 1b last_byte = 7c > >>>>>> current = 1b hit_edge = 1 > >>>>>> Memory content inconsistency at 5e59000 first_byte = 1b last_byte = 1b > >>>>>> current = 1a hit_edge = 1 > >>>>>> ** > >>>>>> ERROR:tests/postcopy-test.c:345:check_guests_ram: 'bad' should be FALSE > >>>>>> GTester: last random seed: R02S9d79166a1ca7e21940a0f4b0b1255d5b > >>>>>> > >>>>> > >>>>> Are you using KVM PR? > >>>>> > >>>>> it was working fine with TCG and KVM HV. > >>>>> > >>>>> Apparently, USERFAULTFD doesn't work with KVM PR. > >>>>> > >>>>> I've already seen this kind of error with nested KVM on Power: > >>>>> guest in guest with KVM PR in host. > >>>>> > >>>>> This problem was reported on IRC by Greg if I remember correctly (CC:) > >>>>> > >>>> > >>>> Yeah I hit this when running make check in a PPC64 BE guest which > >>>> has kvm_pr loaded. I did not find time to investigate though... I've > >>>> switched to run make check on bare metal POWER7 instead. > >>> > >>> Right, it's POWER7 PPC64 BE with kvm_pr. > >>> > >> > >> And you cannot install a PPC64 BE distro on this POWER7 host and use > >> kvm_hv instead ? > > > > Sure, I could get a non-kvm_pr environment. I'm just concerned that > > QEMU 2.8-rc0 is being tagged today and there is a POWER environment > > where "make check" fails. > > > > Is kvm_pr supported by QEMU? > > Basically yes, it's just like Greg said in another mail, it does not get > much attention these days. > > > If it is supported then "make check" ought to pass. > > OK, since nobody got a really, really good idea how to fix this so far: > What about changing the QEMU test to use only tcg for now, so we've got > a clean release with QEMU v2.8? And then afterwards, we can either fix > kvm-pr in the kernel, or introduce some other mechanism to select > whether the test should be run with KVM or not (either a detection of > the KVM type, or an environment variable or something similar). I'm OK if you want to do that for Power; I'd prefer it kept preferring KVM on x86. Dave > Thomas > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK