From patchwork Tue Nov 15 18:48:20 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Huth X-Patchwork-Id: 9430343 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9D0C76047D for ; Tue, 15 Nov 2016 18:48:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8A40B28734 for ; Tue, 15 Nov 2016 18:48:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7C2B328C32; Tue, 15 Nov 2016 18:48:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id C6D7C28734 for ; Tue, 15 Nov 2016 18:48:44 +0000 (UTC) Received: from localhost ([::1]:48171 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6imh-0004a6-Kk for patchwork-qemu-devel@patchwork.kernel.org; Tue, 15 Nov 2016 13:48:43 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6imS-0004Yr-KU for qemu-devel@nongnu.org; Tue, 15 Nov 2016 13:48:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6imP-00065y-Gp for qemu-devel@nongnu.org; Tue, 15 Nov 2016 13:48:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54204) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c6imP-00065d-87 for qemu-devel@nongnu.org; Tue, 15 Nov 2016 13:48:25 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6CC21C0567B1; Tue, 15 Nov 2016 18:48:24 +0000 (UTC) Received: from [10.36.116.123] (ovpn-116-123.ams2.redhat.com [10.36.116.123]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAFImK46002445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Nov 2016 13:48:22 -0500 To: Greg Kurz , "Dr. David Alan Gilbert" References: <20161115110956.5393749d@bahia> <20161115155642.345d1863@bahia> <44b410d5-907c-cff9-0366-a86718bb0352@redhat.com> <20161115174338.GI2038@work-vm> <20161115191306.216341b9@bahia> From: Thomas Huth Message-ID: <81408cfa-c1a2-ce87-8a31-4ae94d49fbfe@redhat.com> Date: Tue, 15 Nov 2016 19:48:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161115191306.216341b9@bahia> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 15 Nov 2016 18:48:24 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] QEMU postcopy-test failing on ppc64 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Laurent Vivier , Stefan Hajnoczi , Andrea Arcangeli , qemu-devel Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP On 15.11.2016 19:13, Greg Kurz wrote: > On Tue, 15 Nov 2016 17:43:39 +0000 > "Dr. David Alan Gilbert" wrote: > >> * 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. > > Even for Power, I'd prefer to keep KVM since the problem only happens with > KVM PR which isn't the preferred way to do KVM on bare metal... until this > get fixed, I'd rather suggest people to run make check with KVM HV. OK ... what do you think about a patch like this: That way, accel=kvm:tcg is only used if the kvm_hv module is loaded, otherwise it will use accel=tcg instead. Thomas diff --git a/tests/postcopy-test.c b/tests/postcopy-test.c --- a/tests/postcopy-test.c +++ b/tests/postcopy-test.c @@ -380,17 +380,19 @@ static void test_migrate(void) " -incoming %s", tmpfs, bootpath, uri); } else if (strcmp(arch, "ppc64") == 0) { + const char *accel; init_bootfile_ppc(bootpath); - cmd_src = g_strdup_printf("-machine accel=kvm:tcg -m 256M" + accel = system("/sbin/lsmod | grep -q kvm_hv") ? "tcg" : "kvm:tcg"; + cmd_src = g_strdup_printf("-machine accel=%s -m 256M" " -name pcsource,debug-threads=on" " -serial file:%s/src_serial" " -drive file=%s,if=pflash,format=raw", - tmpfs, bootpath); - cmd_dst = g_strdup_printf("-machine accel=kvm:tcg -m 256M" + accel, tmpfs, bootpath); + cmd_dst = g_strdup_printf("-machine accel=%s -m 256M" " -name pcdest,debug-threads=on" " -serial file:%s/dest_serial" " -incoming %s", - tmpfs, uri); + accel, tmpfs, uri); } else { g_assert_not_reached(); }