Re: [Qemu-devel] QEMU postcopy-test failing on ppc64

[Laurent Vivier]

On 15/11/2016 13:20, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (address@hidden) wrote:
>> On Tue, Nov 15, 2016 at 10:09 AM, Greg Kurz <address@hidden> wrote:
>>> On Tue, 15 Nov 2016 10:53:35 +0100
>>> Laurent Vivier <address@hidden> 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]

Laurent