Re: [PULL 00/10] migration queue

[Peter Xu <peterx@redhat.com>]

On Sun, Oct 11, 2020 at 07:29:25PM +0100, Peter Maydell wrote:
> > Migration:
> >   Dirtyrate measurement API cleanup
> >   Postcopy recovery fixes
> >
> > Virtiofsd:
> >   Missing qemu_init_exec_dir call
> >   Support for setting the group on socket creation
> >   Stop a gcc warning
> >   Avoid tempdir in sandboxing
> 
> This seems to hang in 'make check' trying to run
> tests/qtest/migration-test on s390x and ppc, ie
> the big-endian hosts.

Hi, Peter,

Do you know what's the page size on both platforms?

Asking because after I debugged I do see a bug in one of the patches, however
it's not about endianess but page size.  Something like:

-------8<----------
diff --git a/migration/migration.c b/migration/migration.c
index d8a5c0de44..ca18b1cf17 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -370,7 +370,7 @@ int migrate_send_rp_message_req_pages(MigrationIncomingState *mis,
 int migrate_send_rp_req_pages(MigrationIncomingState *mis,
                               RAMBlock *rb, ram_addr_t start, uint64_t haddr)
 {
-    void *aligned = (void *)(uintptr_t)(haddr & (-qemu_target_page_size()));
+    void *aligned = (void *)(uintptr_t)(haddr & qemu_real_host_page_mask));
     bool received;
 
     WITH_QEMU_LOCK_GUARD(&mis->page_request_mutex) {
-------8<----------

When I reproduce this issue I was running x86_64 guests on ppc64be hosts (which
has host page size == 64k).  Above fix works for me on that.  So I want to
confirm with you on the s390x failure you mentioned.  If both of them have
special page sizes then it's probably it (AFAICT, the bug could trigger when
guest page size is smaller than host page size).  But I'd like to double
confirm with you before I repost, just in case there's another bug hidden.

I'm also trying to find a s390x host to give it a shot.  However I decided to
also ask this loud so it might be even faster.

Thanks,

-- 
Peter Xu