All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Steve Sistare <steven.sistare@oracle.com>
Cc: qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Juan Quintela" <quintela@redhat.com>,
	"Philippe Mathieu-Daudé" <philippe.mathieu.daude@gmail.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Igor Mammedov" <imammedo@redhat.com>
Subject: Re: [PATCH V2] memory: RAM_NAMED_FILE flag
Date: Tue, 7 Feb 2023 15:23:12 -0500	[thread overview]
Message-ID: <Y+KzMDdc+F9zHMh2@x1n> (raw)
In-Reply-To: <1675796613-235716-1-git-send-email-steven.sistare@oracle.com>

On Tue, Feb 07, 2023 at 11:03:33AM -0800, Steve Sistare wrote:
> migrate_ignore_shared() is an optimization that avoids copying memory
> that is visible and can be mapped on the target.  However, a
> memory-backend-ram or a memory-backend-memfd block with the RAM_SHARED
> flag set is not migrated when migrate_ignore_shared() is true.  This is
> wrong, because the block has no named backing store, and its contents will
> be lost.  To fix, ignore shared memory iff it is a named file.  Define a
> new flag RAM_NAMED_FILE to distinguish this case.

There's also TYPE_MEMORY_BACKEND_EPC.  Reading the commit message it seems
it can still be used in similar ways.  Pasting commit message from c6c0232:

    Because of its unique requirements, Linux manages EPC separately from
    normal memory.  Similar to memfd, the device /dev/sgx_vepc can be
    opened to obtain a file descriptor which can in turn be used to mmap()
    EPC memory.

I'm not sure whether it means that should apply for RAM_NAMED_FILE too,
neither do I think it's super important..  Still better to define it
properly.

Another comment is, AFAIK this patch will modify senamtics of the old
capability "x-ignore-shared".  But I'd say in a sensible way.  Maybe worth
directly modify qapi/migration.json to reflect it (especially it's x-
prefixed) to something like:

# @x-ignore-shared: If enabled, QEMU will not migrate named shared memory
#                   (since 4.0) 

Thanks,

-- 
Peter Xu



  reply	other threads:[~2023-02-07 20:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07 19:03 [PATCH V2] memory: RAM_NAMED_FILE flag Steve Sistare
2023-02-07 20:23 ` Peter Xu [this message]
2023-02-08 18:34   ` Steven Sistare
     [not found]     ` <Y+P2k6iDQc0x0xtT@x1n>
2023-06-07 14:05       ` Steven Sistare
2023-06-07 14:48         ` 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=Y+KzMDdc+F9zHMh2@x1n \
    --to=peterx@redhat.com \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philippe.mathieu.daude@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=steven.sistare@oracle.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.