All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Pankaj Gupta" <pankaj.gupta@cloud.ionos.com>,
	teawater <teawaterz@linux.alibaba.com>,
	qemu-devel@nongnu.org, "Peter Xu" <peterx@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Marek Kedzierski" <mkedzier@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Andrey Gruzdev" <andrey.gruzdev@virtuozzo.com>,
	"Wei Yang" <richard.weiyang@linux.alibaba.com>
Subject: Re: [PATCH v1 6/9] migration/postcopy: Handle RAMBlocks with a RamDiscardManager on the destination
Date: Mon, 01 Nov 2021 19:21:14 +0100	[thread overview]
Message-ID: <87sfwfspnp.fsf@secure.mitica> (raw)
In-Reply-To: <20211011175346.15499-7-david@redhat.com> (David Hildenbrand's message of "Mon, 11 Oct 2021 19:53:43 +0200")

David Hildenbrand <david@redhat.com> wrote:
> Currently, when someone (i.e., the VM) accesses discarded parts inside a
> RAMBlock with a RamDiscardManager managing the corresponding mapped memory
> region, postcopy will request migration of the corresponding page from the
> source. The source, however, will never answer, because it refuses to
> migrate such pages with undefined content ("logically unplugged"): the
> pages are never dirty, and get_queued_page() will consequently skip
> processing these postcopy requests.
>
> Especially reading discarded ("logically unplugged") ranges is supposed to
> work in some setups (for example with current virtio-mem), although it
> barely ever happens: still, not placing a page would currently stall the
> VM, as it cannot make forward progress.
>
> Let's check the state via the RamDiscardManager (the state e.g.,
> of virtio-mem is migrated during precopy) and avoid sending a request
> that will never get answered. Place a fresh zero page instead to keep
> the VM working. This is the same behavior that would happen
> automatically without userfaultfd being active, when accessing virtual
> memory regions without populated pages -- "populate on demand".
>
> For now, there are valid cases (as documented in the virtio-mem spec) where
> a VM might read discarded memory; in the future, we will disallow that.
> Then, we might want to handle that case differently, e.g., warning the
> user that the VM seems to be mis-behaving.
>
> Reviewed-by: Peter Xu <peterx@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>



  reply	other threads:[~2021-11-01 19:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11 17:53 [PATCH v1 0/9] migration/ram: Optimize for virtio-mem via RamDiscardManager David Hildenbrand
2021-10-11 17:53 ` [PATCH v1 1/9] memory: Introduce replay_discarded callback for RamDiscardManager David Hildenbrand
2021-11-01 12:49   ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 2/9] virtio-mem: Implement replay_discarded RamDiscardManager callback David Hildenbrand
2021-11-01 18:10   ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 3/9] migration/ram: Don't passs RAMState to migration_clear_memory_region_dirty_bitmap_*() David Hildenbrand
2021-11-01 12:46   ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 4/9] migration/ram: Handle RAMBlocks with a RamDiscardManager on the migration source David Hildenbrand
2021-11-01 18:14   ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 5/9] virtio-mem: Drop precopy notifier David Hildenbrand
2021-11-01 18:15   ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 6/9] migration/postcopy: Handle RAMBlocks with a RamDiscardManager on the destination David Hildenbrand
2021-11-01 18:21   ` Juan Quintela [this message]
2021-10-11 17:53 ` [PATCH v1 7/9] migration: Simplify alignment and alignment checks David Hildenbrand
2021-10-14  9:33   ` Philippe Mathieu-Daudé
2021-11-01 18:27   ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 8/9] migration/ram: Factor out populating pages readable in ram_block_populate_pages() David Hildenbrand
2021-11-01 18:32   ` Juan Quintela
2021-10-11 17:53 ` [PATCH v1 9/9] migration/ram: Handle RAMBlocks with a RamDiscardManager on background snapshots David Hildenbrand
2021-11-01 18:35   ` Juan Quintela
2021-10-13 17:35 ` [PATCH v1 0/9] migration/ram: Optimize for virtio-mem via RamDiscardManager Dr. David Alan Gilbert
2021-10-14  8:43   ` David Hildenbrand
2021-10-14  8:43   ` David Hildenbrand

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=87sfwfspnp.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=andrey.gruzdev@virtuozzo.com \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=mkedzier@redhat.com \
    --cc=mst@redhat.com \
    --cc=pankaj.gupta@cloud.ionos.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.weiyang@linux.alibaba.com \
    --cc=teawaterz@linux.alibaba.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 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.