From: Igor Mammedov <imammedo@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Richard Henderson" <rth@twiddle.net>,
"Eduardo Habkost" <ehabkost@redhat.com>,
stefanha@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH 0/2] RFC: add -mem-shared option
Date: Fri, 29 Nov 2019 11:23:29 +0100 [thread overview]
Message-ID: <20191129112329.336582b7@redhat.com> (raw)
In-Reply-To: <fb122bbe-3fc4-e3cd-899a-c3538237203a@redhat.com>
On Fri, 29 Nov 2019 10:31:36 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 28/11/19 17:10, Eduardo Habkost wrote:
> > On Thu, Nov 28, 2019 at 06:15:16PM +0400, Marc-André Lureau wrote:
> >> Hi,
> >>
> >> Setting up shared memory for vhost-user is a bit complicated from
> >> command line, as it requires NUMA setup such as: m 4G -object
> >> memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on -numa
> >> node,memdev=mem.
> >>
> >> Instead, I suggest to add a -mem-shared option for non-numa setups,
> >> that will make the -mem-path or anonymouse memory shareable.
> >
> > Can we make this be a "-m" option?
> >
> > Or, even better: can we make "-m" options be automatically
> > translated to memory-backend-* options somehow?
> >
[...]
> Therefore, I think instead of -mem-shared we should add a "-m
> memdev=..." option. This option:
>
> * would be mutually exclusive with both -mem-path
>
> * would be handled from allocate_system_memory_nonnuma.
>
> * could be mutually exclusive "-numa node", or could just be mutually
> exclusive with "-numa node,memdev=..." (the logical conclusion of that
> however would be an undeprecation of "-numa node,mem=...", so that has
> to be taken into account as well).
the plan was/still is to have memdev for main ram and deprecate
"-numa node,mem=..." for new machine types (can't be done for
old ones due to migration breakages and old libvirt which uses
it). So new machines will be forced to use "-numa memdev"
For old machines '-m memdev' provided memory region will used to
keep "-numa node,mem=..." working as it's now (however broken it is).
>
> Paolo
>
>
next prev parent reply other threads:[~2019-11-29 11:23 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-28 14:15 [PATCH 0/2] RFC: add -mem-shared option Marc-André Lureau
2019-11-28 14:15 ` [PATCH 1/2] memfd: add qemu_memfd_open() Marc-André Lureau
2019-11-28 14:15 ` [PATCH 2/2] Add -mem-shared option Marc-André Lureau
2019-11-28 16:14 ` Eduardo Habkost
2019-11-28 16:28 ` Igor Mammedov
2019-11-28 20:31 ` Marc-André Lureau
2019-11-29 10:07 ` Igor Mammedov
2019-11-29 10:11 ` Paolo Bonzini
2019-11-29 12:01 ` Markus Armbruster
2019-11-29 20:31 ` Eduardo Habkost
2019-11-29 12:16 ` Igor Mammedov
2019-11-29 17:46 ` Paolo Bonzini
2019-12-02 7:39 ` Igor Mammedov
2019-12-02 21:00 ` Eduardo Habkost
2019-12-03 8:56 ` Thomas Huth
2019-12-03 14:43 ` Igor Mammedov
2019-12-09 20:58 ` Eduardo Habkost
2019-12-10 10:34 ` Markus Armbruster
2019-12-10 13:09 ` Igor Mammedov
2019-12-03 21:34 ` Eduardo Habkost
2019-11-28 16:10 ` [PATCH 0/2] RFC: add " Eduardo Habkost
2019-11-29 9:18 ` Igor Mammedov
2019-11-29 9:31 ` Paolo Bonzini
2019-11-29 10:23 ` Igor Mammedov [this message]
2019-11-29 11:21 ` Paolo Bonzini
2019-11-29 20:21 ` Eduardo Habkost
2019-12-01 15:40 ` Marc-André Lureau
2019-12-01 18:03 ` Paolo Bonzini
2019-11-28 16:59 ` Dr. David Alan Gilbert
2019-11-29 9:23 ` Igor Mammedov
2019-12-13 11:39 ` Stefan Hajnoczi
2019-12-13 13:12 ` Igor Mammedov
2019-11-29 4:37 ` no-reply
2019-11-29 5:34 ` no-reply
2019-11-29 7:02 ` Gerd Hoffmann
2019-11-29 7:30 ` Marc-André Lureau
2019-11-29 9:27 ` Daniel P. Berrangé
2019-11-29 9:31 ` Marc-André Lureau
2019-11-29 9:42 ` Daniel P. Berrangé
2019-11-29 9:45 ` Marc-André Lureau
2019-11-29 11:44 ` Gerd Hoffmann
2019-11-29 9:33 ` Paolo Bonzini
2019-11-29 9:39 ` Daniel P. Berrangé
2019-11-29 9:52 ` Paolo Bonzini
2019-11-29 10:13 ` Igor Mammedov
2019-11-29 11:20 ` Paolo Bonzini
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=20191129112329.336582b7@redhat.com \
--to=imammedo@redhat.com \
--cc=ehabkost@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=stefanha@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
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.