linux-kernel - Re: [PATCH 2/2] KVM: selftests: Enable dirty_log

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 30 Jul 2019 20:04:01 +0200
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     Thomas Huth <thuth@...hat.com>, kvm@...r.kernel.org,
        Janosch Frank <frankja@...ux.ibm.com>
Cc:     linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-s390@...r.kernel.org, David Hildenbrand <david@...hat.com>,
        Cornelia Huck <cohuck@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Shuah Khan <shuah@...nel.org>, Peter Xu <peterx@...hat.com>
Subject: Re: [PATCH 2/2] KVM: selftests: Enable dirty_log_test on s390x



On 30.07.19 19:11, Thomas Huth wrote:
> On 30/07/2019 16.57, Christian Borntraeger wrote:
>>
>>
>> On 30.07.19 12:01, Thomas Huth wrote:
>>> To run the dirty_log_test on s390x, we have to make sure that we
>>> access the dirty log bitmap with little endian byte ordering and
>>> we have to properly align the memslot of the guest.
>>> Also all dirty bits of a segment are set once on s390x when one
>>> of the pages of a segment are written to for the first time, so
>>> we have to make sure that we touch all pages during the first
>>> iteration to keep the test in sync here.
>>
>> While this fixes the test (and the migration does work fine), it still
>> means that s390x overindicates the dirty bit for sparsely populated
>> 1M segments. It is just a performance issue, but maybe we should try 
>> to get this fixed.
> 
> I hope you don't expect me to fix this - the gmap code is really not my
> turf...

No, this is clearly on our turf. 
> 
>> Not sure what to do here to remember us about this, 
>> adding this as expected fail?
> 
> There is no such thing like an expected failure in KVM selftests -
> that's only available in kvm-unit-tests.
> 
> So the only option that I currently see is to add a printf("TODO: ...")
> on s390x here... would that work for you?

Maybe just keep this as is - we should just not forget about it.