qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: zhukeqian <zhukeqian1@huawei.com>
Cc: Zenghui Yu <yuzenghui@huawei.com>,
	pbonzini@redhat.com, qemu-devel@nongnu.org,
	wanghaibin.wang@huawei.com
Subject: Re: [PATCH] kvm: Take into account the unaligned section size when preparing bitmap
Date: Mon, 14 Dec 2020 10:36:25 -0500	[thread overview]
Message-ID: <20201214153625.GF6520@xz-x1> (raw)
In-Reply-To: <41d9ac96-83af-e8c3-6e54-c702f5527f5e@huawei.com>

On Mon, Dec 14, 2020 at 10:14:11AM +0800, zhukeqian wrote:

[...]

> >>> Though indeed I must confess I don't know how it worked in general when host
> >>> page size != target page size, at least for migration.  For example, I believe
> >>> kvm dirty logging is host page size based, though migration should be migrating
> >>> pages in guest page size granule when it spots a dirty bit set.

[1]

> Hi Peter,

Keqian,

> > OTOH I'm more worried on the other question on how we handle guest psize !=
> > host psize case for migration now...
> I think it does not matter when guest_psize != host_psize, as we only need to interact with
> stage2 page tables during migration. Stage2 is enough to tracking guest dirty memory, and even
> if guest close stage1, we also can do a successful migration.

I don't know why 2-stage matters here, since I believe KVM can track dirty
pages either using two dimentional paging or shadowing, however it's always
done in host small page size.  The question I'm confused is there seems to have
a size mismatch between qemu migration and what kvm does [1].  For example, how
migration works on ARM64 where host has psize==4K while guest has psize=64K.

Thanks,

-- 
Peter Xu



  reply	other threads:[~2020-12-14 15:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-08 11:40 [PATCH] kvm: Take into account the unaligned section size when preparing bitmap Zenghui Yu
2020-12-08 15:16 ` Peter Xu
2020-12-09  2:33   ` Zenghui Yu
2020-12-09 21:09     ` Peter Xu
2020-12-10  4:23       ` Zenghui Yu
2020-12-10  1:46     ` zhukeqian
2020-12-10  2:08       ` Peter Xu
2020-12-10  2:53         ` zhukeqian
2020-12-10  3:31           ` Zenghui Yu
2020-12-10 14:50           ` Peter Xu
2020-12-11  1:13             ` zhukeqian
2020-12-11 15:25               ` Peter Xu
2020-12-14  2:14                 ` zhukeqian
2020-12-14 15:36                   ` Peter Xu [this message]
2020-12-15  7:23                     ` zhukeqian
2020-12-15  7:39                       ` Zenghui Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201214153625.GF6520@xz-x1 \
    --to=peterx@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wanghaibin.wang@huawei.com \
    --cc=yuzenghui@huawei.com \
    --cc=zhukeqian1@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).