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]
Message-ID: <02c5c7b4-c45e-4573-d2c3-ebfa2cd2c9d1@redhat.com>
Date:   Tue, 30 Jul 2019 19:11:23 +0200
From:   Thomas Huth <thuth@...hat.com>
To:     Christian Borntraeger <borntraeger@...ibm.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/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...

> 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?

 Thomas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ