On 15.11.2016 16:18, Stefan Hajnoczi wrote: > On Tue, Nov 15, 2016 at 2:56 PM, Greg Kurz <gr...@kaod.org> wrote: >> On Tue, 15 Nov 2016 11:14:57 +0000 >> Stefan Hajnoczi <stefa...@gmail.com> wrote: >> >>> On Tue, Nov 15, 2016 at 10:09 AM, Greg Kurz <gr...@kaod.org> wrote: >>>> On Tue, 15 Nov 2016 10:53:35 +0100 >>>> Laurent Vivier <lviv...@redhat.com> 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). Thomas
