Re: [PATCH] kvm: Take into account the unaligned section size when preparing bitmap

[Zenghui Yu]

Hi Keqian, Peter,

On 2020/12/15 15:23, zhukeqian wrote:
> On 2020/12/14 23:36, Peter Xu wrote:
> > 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.
> Hi Peter,
>
> OK, I got it ;-) Do you mean qemu_real_host_page_size != TARGET_PAGE_SIZE?
> After my analysis, I see that when qemu_real_host_page_size != TARGET_PAGE_SIZE,
> there are some problems indeed. I have send out some patches, please check 
> whether they solve this
> problem, thanks!

Now I see what your concern is :) Thanks both for the explanation and
the further fix!


Zenghui