On 30.07.19 20:04, Christian Borntraeger wrote: > > > 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. FWIW, we share the pagetables with the userspace process. We mark a page as dirty (PGSTE_UC_BIT) when - We modify the storage key - We map a PTE as RW (pgste_set_pte()) I assume all PTEs of the segment are mapped RW (for example, if user space wrote to such a PTE), that is why we have the PGSTE_UC_BIT bit set. As PGSTE_UC_BIT also tracks what userspace did, not only KVM via the GMAP, this might indeed be correct. -- Thanks, David / dhildenb
