QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Peter Xu <peterx@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Tian Kevin <kevin.tian@intel.com>,
	qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>
Subject: Re: [PATCH RFC 0/4] vl: Sync dirty bitmap when system resets
Date: Sat, 23 May 2020 18:49:32 -0400
Message-ID: <20200523224932.GA939059@xz-x1> (raw)
In-Reply-To: <20200502210423.GB6299@xz-x1>

On Sat, May 02, 2020 at 05:04:23PM -0400, Peter Xu wrote:
> Paolo,
> 
> Do you have any opinion on this series?  Or more generally comments on what's
> your preference to fix the known dirty sync issue with memslot removal would be
> welcomed too.  For my own opinion, I prefer the approach with this series so we
> won't need to touch the kernel at all, and it also paves the way for dirty
> ring.  In all cases, I do think collecting dirty bit of a removing slot is
> slightly awkward already.
> 
> Dave has valid conerns about other cases besides reboot where we might still
> want to keep the dirty bits, on either (1) during BIOS/... boots, or (2) guest
> unmaps of device mmio regions that were backed up by RAM.  I can continue to
> look into theses, however before that I'd appreciate to know whether the
> direction is correct and acceptable.
> 
> IMHO the worst case of a series like this could be that we got regression on
> dirty bit loss, but then we can simply revert the last patch to verify or fix
> it (or we can fix the missing case instead).

Hmm... I didn't find a good and clean way to cover what Dave has mentioned.
Everything would be either ugly or even uglier.  Sad.

Since I didn't get any feedback either on this for some time (or the rest of
the discussion threads or proposals I opened), I think it's time to move on...
I start to feel unwise to continue have the two kvm dirty ring series blocked
due to this extremely corner case of race condition, after all it's not a
specific problem to kvm dirty ring but to both of the methods.  I'll continue
with dirty ring for now, then we fix the race altogether with dirty log when we
find some better solution.

I'll soon post a new QEMU version, keeping the removing memslot sync operation,
but just like dirty log it'll be a best effort sync (e.g. PML ignored).
However I'll comment to at least mention the issues we've found so we can get
to it later again.

Thanks,

-- 
Peter Xu



      reply index

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 19:42 Peter Xu
2020-04-28 19:42 ` [PATCH RFC 1/4] migration: Export migration_bitmap_sync_precopy() Peter Xu
2020-05-06  9:58   ` Dr. David Alan Gilbert
2020-04-28 19:42 ` [PATCH RFC 2/4] migration: Introduce migrate_is_precopy() Peter Xu
2020-05-06 10:05   ` Dr. David Alan Gilbert
2020-05-06 14:52     ` Peter Xu
2020-04-28 19:42 ` [PATCH RFC 3/4] vl: Sync dirty bits for system resets during precopy Peter Xu
2020-05-06 10:53   ` Dr. David Alan Gilbert
2020-05-06 15:38     ` Peter Xu
2020-04-28 19:42 ` [PATCH RFC 4/4] kvm: No need to sync dirty bitmap before memslot removal any more Peter Xu
2020-04-29 13:26 ` [PATCH RFC 0/4] vl: Sync dirty bitmap when system resets Dr. David Alan Gilbert
2020-04-29 14:32   ` Peter Xu
2020-05-02 21:04     ` Peter Xu
2020-05-23 22:49       ` Peter Xu [this message]

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=20200523224932.GA939059@xz-x1 \
    --to=peterx@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=kevin.tian@intel.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.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

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
		qemu-devel@nongnu.org
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git