From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6jwK-0004XE-9F for qemu-devel@nongnu.org; Tue, 15 Nov 2016 15:02:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6jwH-00074a-4j for qemu-devel@nongnu.org; Tue, 15 Nov 2016 15:02:44 -0500 Received: from 3.mo53.mail-out.ovh.net ([178.33.44.239]:36100) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c6jwG-000747-UB for qemu-devel@nongnu.org; Tue, 15 Nov 2016 15:02:41 -0500 Received: from player158.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo53.mail-out.ovh.net (Postfix) with ESMTP id 5083F43383 for ; Tue, 15 Nov 2016 21:02:39 +0100 (CET) Date: Tue, 15 Nov 2016 21:02:33 +0100 From: Greg Kurz Message-ID: <20161115210233.3b706c58@bahia> In-Reply-To: References: <20161115110956.5393749d@bahia> <20161115122056.GG2038@work-vm> <97c72871-71f8-9385-c67d-45bc32e4c9c8@redhat.com> <20161115144830.GC17672@stefanha-x1.localdomain> <20161115160338.4b6f0cf6@bahia> <6f46cafc-d72b-f7dd-db3e-e4aa24f20134@redhat.com> <20161115190148.4adf7691@bahia> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] QEMU postcopy-test failing on ppc64 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Vivier Cc: Stefan Hajnoczi , "Dr. David Alan Gilbert" , Thomas Huth , qemu-devel On Tue, 15 Nov 2016 19:24:24 +0100 Laurent Vivier wrote: > On 15/11/2016 19:01, Greg Kurz wrote: > > On Tue, 15 Nov 2016 16:07:40 +0100 > > Laurent Vivier wrote: > > > >> On 15/11/2016 16:03, Greg Kurz wrote: > >>> On Tue, 15 Nov 2016 14:48:30 +0000 > >>> Stefan Hajnoczi wrote: > >>> > >>>> On Tue, Nov 15, 2016 at 01:58:38PM +0100, Laurent Vivier wrote: > >>>>> > >>>>> > >>>>> On 15/11/2016 13:20, Dr. David Alan Gilbert wrote: > >>>>>> * Stefan Hajnoczi (stefanha@gmail.com) 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. > >>>>>>> > >>>>>>> If this should be fixed for QEMU 2.8 please add it to > >>>>>>> http://qemu-project.org/Planning/2.8 and I'll track it (i.e. won't > >>>>>>> release before it's resolved). > >>>>>>> > >>>>>>> If this is a known issue that will be in QEMU 2.8 please add it to > >>>>>>> http://qemu-project.org/ChangeLog/2.8#Known_issues. > >>>>>> > >>>>>> I don't think it's new with 2.8 (Laurent?) and I think it's actually > >>>>>> a kernel issue that needs fixing. > >>>>> > >>>>> I's not a regression and I think it's a kernel issue. > >>>>> > >>>>> As it has never worked with KVM PR and can't be fixed at QEMU level, we > >>>>> can't solve it for 2.8 (no tracking). > >>>>> > >>>>> I'm going to update the know issues for 2.8. > >>>>> [and I'm going to try to understand what really happens] > >>>> > >>>> Should the test be skipped on KVM PR? > >>>> > >>>> It's a shame that make check fails. > >>>> > >>> > >>> Yeah I agree this is lame but KVM PR isn't very cherished these days... > >>> > >>> Since postcopy-test runs QEMU with -accel kvm:tcg, a possible workaround is > >>> to kick KVM out of the environment you're running make check in. > >> > >> Moreover, using "-accel kvm:tcg" induces an error when the test is > >> running in cross-arch case (ppc on intel, or intel on ppc). > >> > > > > You're talking about the '"kvm" accelerator not found' error ? > > Yes > > > > >> But I think postcopy is typically something we should test with KVM, not > >> TCG, as there are some kernel dependencies (USERFAULTFD). > >> > > > > I agree it should be tested with KVM when applicable but I don't understand > > the 'not TCG' since it is the only way to test when you don't have access > > to specific hardware... > > I agree; What I mean is we must test this preferably with KVM because it > is more likely to have a problem with KVM than with TCG because of the > MMU virtualization. > Fair enough but this doesn't address the problem we currently have: a broken KVM can cause make check to fail... and BTW, until the root cause is found, I'm not sure if the culprit is KVM PR alone or QEMU+KVM PR... Cheers. -- Greg > >> It has been suggested a while to use an environment variable, like for > >> kvm-unit-tests, something like QTEST_ACCEL="kvm". > >> > > > > Yeah, I think it would be better than "-accel kvm:tcg" > > > >> Laurent > > > > Cheers. > > > > -- > > Greg > > Thanks, > Laurent