qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Steve Sistare <steven.sistare@oracle.com>,
	qemu-devel@nongnu.org, Fabiano Rosas <farosas@suse.de>,
	David Hildenbrand <david@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Philippe Mathieu-Daude <philmd@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [PATCH V2 01/11] machine: alloc-anon option
Date: Wed, 17 Jul 2024 15:24:20 -0400	[thread overview]
Message-ID: <ZpgaZPxKzwcVAYZn@x1n> (raw)
In-Reply-To: <20240716111955.01d1d2b9@imammedo.users.ipa.redhat.com>

On Tue, Jul 16, 2024 at 11:19:55AM +0200, Igor Mammedov wrote:
> On Sun, 30 Jun 2024 12:40:24 -0700
> Steve Sistare <steven.sistare@oracle.com> wrote:
> 
> > Allocate anonymous memory using mmap MAP_ANON or memfd_create depending
> > on the value of the anon-alloc machine property.  This affects
> > memory-backend-ram objects, guest RAM created with the global -m option
> > but without an associated memory-backend object and without the -mem-path
> > option
> nowadays, all machines were converted to use memory backend for VM RAM.
> so -m option implicitly creates memory-backend object,
> which will be either MEMORY_BACKEND_FILE if -mem-path present
> or MEMORY_BACKEND_RAM otherwise.
> 
> 
> > To access the same memory in the old and new QEMU processes, the memory
> > must be mapped shared.  Therefore, the implementation always sets
> 
> > RAM_SHARED if alloc-anon=memfd, except for memory-backend-ram, where the
> > user must explicitly specify the share option.  In lieu of defining a new
> so statement at the top that memory-backend-ram is affected is not
> really valid? 
> 
> > RAM flag, at the lowest level the implementation uses RAM_SHARED with fd=-1
> > as the condition for calling memfd_create.
> 
> In general I do dislike adding yet another option that will affect
> guest RAM allocation (memory-backends  should be sufficient).

I shared the same concern when reviewing the previous version, and I keep
having so.

> 
> However I do see that you need memfd for device memory (vram, roms, ...).
> Can we just use memfd/shared unconditionally for those and
> avoid introducing a new confusing option?

ROMs should be fine IIUC, as they shouldn't be large, and they can be
migrated normally (because they're not DMA target from VFIO assigned
devices).  IOW, per my understanding what must be shared via memfd is
writable memories that can be DMAed from a VFIO device.

I raised such question on whether / why vram can be a DMA target, but I
didn't get a response.  So I would like to redo this comment: I think we
should figure out what is missing when we switch all backends to use
-object, rather than adding this flag easily.  When added, we should be
crystal clear on which RAM region will be applicable by this flag.

PS to Steve: and I think I left tons of other comments in previous version
outside this patch too, but I don't think they're fully discussed when this
series was sent.  I can re-read the series again, but I don't think it'll
work out if we keep skipping discussions..

Thanks,

-- 
Peter Xu



  reply	other threads:[~2024-07-17 19:25 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-30 19:40 [PATCH V2 00/11] Live update: cpr-exec Steve Sistare
2024-06-30 19:40 ` [PATCH V2 01/11] machine: alloc-anon option Steve Sistare
2024-07-15 17:52   ` Fabiano Rosas
2024-07-16  9:19   ` Igor Mammedov
2024-07-17 19:24     ` Peter Xu [this message]
2024-07-18 15:43       ` Steven Sistare
2024-07-18 16:22         ` Peter Xu
2024-07-20 20:35       ` Steven Sistare
2024-08-04 16:20         ` Peter Xu
2024-07-20 20:28     ` Steven Sistare
2024-07-22  9:10       ` David Hildenbrand
2024-07-29 12:29       ` Igor Mammedov
2024-08-08 18:32         ` Steven Sistare
2024-08-12 18:37           ` Steven Sistare
2024-08-13 15:35             ` Peter Xu
2024-08-13 17:00               ` Alex Williamson
2024-08-13 18:45                 ` Peter Xu
2024-08-13 18:56                   ` Steven Sistare
2024-08-13 18:46                 ` Steven Sistare
2024-08-13 18:49                   ` Steven Sistare
2024-08-13 17:34               ` Steven Sistare
2024-08-13 19:02                 ` Peter Xu
2024-06-30 19:40 ` [PATCH V2 02/11] migration: cpr-state Steve Sistare
2024-07-17 18:39   ` Fabiano Rosas
2024-07-19 15:03   ` Peter Xu
2024-07-20 19:53     ` Steven Sistare
2024-06-30 19:40 ` [PATCH V2 03/11] migration: save cpr mode Steve Sistare
2024-07-17 18:39   ` Fabiano Rosas
2024-07-18 15:47     ` Steven Sistare
2024-06-30 19:40 ` [PATCH V2 04/11] migration: stop vm earlier for cpr Steve Sistare
2024-07-17 18:59   ` Fabiano Rosas
2024-07-20 20:00     ` Steven Sistare
2024-07-22 13:42       ` Fabiano Rosas
2024-08-06 20:52         ` Steven Sistare
2024-06-30 19:40 ` [PATCH V2 05/11] physmem: preserve ram blocks " Steve Sistare
2024-06-30 19:40 ` [PATCH V2 06/11] migration: fix mismatched GPAs during cpr Steve Sistare
2024-07-19 16:28   ` Peter Xu
2024-07-20 21:28     ` Steven Sistare
2024-08-07 21:04     ` Steven Sistare
2024-08-13 20:43       ` Peter Xu
2024-08-15 20:54         ` Steven Sistare
2024-08-16 14:43           ` Peter Xu
2024-08-16 17:10             ` Steven Sistare
2024-08-21 16:57               ` Peter Xu
2024-06-30 19:40 ` [PATCH V2 07/11] oslib: qemu_clear_cloexec Steve Sistare
2024-06-30 19:40 ` [PATCH V2 08/11] vl: helper to request exec Steve Sistare
2024-06-30 19:40 ` [PATCH V2 09/11] migration: cpr-exec-command parameter Steve Sistare
2024-06-30 19:40 ` [PATCH V2 10/11] migration: cpr-exec save and load Steve Sistare
2024-06-30 19:40 ` [PATCH V2 11/11] migration: cpr-exec mode Steve Sistare
2024-07-18 15:56 ` [PATCH V2 00/11] Live update: cpr-exec Peter Xu
2024-07-20 21:26   ` Steven Sistare
2024-08-04 16:10     ` Peter Xu
2024-08-07 19:47       ` Steven Sistare
2024-08-13 20:12         ` Peter Xu
2024-08-20 16:28           ` [PATCH V2 00/11] Live update: cpr-exec (reconnections) Steven Sistare
2024-07-22  8:59   ` [PATCH V2 00/11] Live update: cpr-exec David Hildenbrand
2024-08-04 15:43     ` Peter Xu
2024-08-05  9:52       ` David Hildenbrand
2024-08-05 10:06         ` David Hildenbrand
2024-08-05 10:01   ` Daniel P. Berrangé
2024-08-06 20:56     ` Steven Sistare
2024-08-13 19:46       ` Peter Xu
2024-08-15 20:55         ` Steven Sistare
2024-08-16 15:06           ` Peter Xu
2024-08-16 15:16             ` Daniel P. Berrangé
2024-08-16 15:19               ` Steven Sistare
2024-08-16 15:34               ` Peter Xu
2024-08-16 16:00                 ` Daniel P. Berrangé
2024-08-16 16:17                   ` Peter Xu
2024-08-16 16:28                     ` Daniel P. Berrangé
2024-08-16 17:09                     ` Steven Sistare
2024-08-21 18:34                       ` Peter Xu
2024-09-04 20:58                         ` Steven Sistare
2024-09-04 22:23                           ` Peter Xu
2024-09-05  9:49                             ` Daniel P. Berrangé
2024-09-05  9:43                           ` Daniel P. Berrangé
2024-09-05  9:30                       ` Daniel P. Berrangé

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=ZpgaZPxKzwcVAYZn@x1n \
    --to=peterx@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=david@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=farosas@suse.de \
    --cc=imammedo@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).