From: Igor Mammedov <imammedo@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, dgilbert@redhat.com
Subject: Re: [PATCH 0/2] kvm: clear dirty bitmaps from all overlapping memslots
Date: Mon, 23 Sep 2019 18:15:12 +0200 [thread overview]
Message-ID: <20190923181512.144e3b77@redhat.com> (raw)
In-Reply-To: <20190923012946.GJ12858@xz-x1>
On Mon, 23 Sep 2019 09:29:46 +0800
Peter Xu <peterx@redhat.com> wrote:
> On Fri, Sep 20, 2019 at 03:58:51PM +0200, Igor Mammedov wrote:
> > On Fri, 20 Sep 2019 20:19:51 +0800
> > Peter Xu <peterx@redhat.com> wrote:
> >
> > > On Fri, Sep 20, 2019 at 12:21:20PM +0200, Paolo Bonzini wrote:
> > > > A single ram_addr (representing a host-virtual address) could be aliased
> > > > to multiple guest physical addresses. Since the KVM dirty page reporting
> > > > works on guest physical addresses, we need to clear all of the aliases
> > > > when a page is migrated, or there is a risk of losing writes to the
> > > > aliases that were not cleared.
> > >
> > > (CCing Igor too so Igor would be aware of these changes that might
> > > conflict with the recent memslot split work)
> > >
> >
> > Thanks Peter,
> > I'll rebase on top of this series and do some more testing
>
> Igor,
>
> It turns out that this series is probably not required for the current
> tree because memory_region_clear_dirty_bitmap() should have handled
> the aliasing issue correctly, but then this patchset will be a
> pre-requisite of your split series because when we split memory slots
> it starts to be possible that log_clear() will be applied to multiple
> kvm memslots.
>
> Would you like to pick these two patches directly into your series?
> The 1st paragraph in the 2nd patch could probably be inaccurate and
> need amending (as mentioned).
Yep, commit message doesn't fit patch, how about following description:
"
Currently MemoryRegionSection has 1:1 mapping to KVMSlot.
However next patch will allow splitting MemoryRegionSection into
several KVMSlot-s, make sure that kvm_physical_log_slot_clear()
is able to handle such 1:N mapping.
"
>
> Thanks,
>
next prev parent reply other threads:[~2019-09-23 16:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-20 10:21 [PATCH 0/2] kvm: clear dirty bitmaps from all overlapping memslots Paolo Bonzini
2019-09-20 10:21 ` [PATCH 1/2] kvm: extract kvm_log_clear_one_slot Paolo Bonzini
2019-09-20 12:11 ` Peter Xu
2019-09-20 10:21 ` [PATCH 2/2] kvm: clear dirty bitmaps from all overlapping memslots Paolo Bonzini
2019-09-20 12:18 ` Peter Xu
2019-09-20 14:03 ` Paolo Bonzini
2019-09-20 12:19 ` [PATCH 0/2] " Peter Xu
2019-09-20 13:58 ` Igor Mammedov
2019-09-23 1:29 ` Peter Xu
2019-09-23 16:15 ` Igor Mammedov [this message]
2019-09-23 16:49 ` Paolo Bonzini
2019-09-24 2:53 ` Peter Xu
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=20190923181512.144e3b77@redhat.com \
--to=imammedo@redhat.com \
--cc=dgilbert@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.