From: Igor Mammedov <imammedo@redhat.com>
To: "Tan, Jianfeng" <jianfeng.tan@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Jason Wang <jasowang@redhat.com>,
Maxime Coquelin <maxime.coquelin@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
Date: Mon, 26 Feb 2018 13:55:49 +0100 [thread overview]
Message-ID: <20180226135549.34af5dbf@redhat.com> (raw)
In-Reply-To: <ED26CBA2FAD1BF48A8719AEF02201E365144EAAB@SHSMSX103.ccr.corp.intel.com>
On Sat, 24 Feb 2018 03:11:30 +0000
"Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
> > -----Original Message-----
> > From: Tan, Jianfeng
> > Sent: Saturday, February 24, 2018 11:08 AM
> > To: 'Igor Mammedov'
> > Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-devel@nongnu.org;
> > Michael S . Tsirkin
> > Subject: RE: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> > migration
> >
> > Hi Igor and all,
> >
> > > -----Original Message-----
> > > From: Igor Mammedov [mailto:imammedo@redhat.com]
> > > Sent: Thursday, February 8, 2018 7:30 PM
> > > To: Tan, Jianfeng
> > > Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-
> > devel@nongnu.org;
> > > Michael S . Tsirkin
> > > Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> > > migration
> > >
> > [...]
> > > > > It could be solved by adding memdev option to machine,
> > > > > which would allow to specify backend object. And then on
> > > > > top make -mem-path alias new option to clean thing up.
> > > >
> > > > Do you mean?
> > > >
> > > > src vm: -m xG
> > > > dst vm: -m xG,memdev=pc.ram -object memory-backend-
> > file,id=pc.ram,size=xG,mem-path=xxx,share=on ...
> > > Yep, I've meant something like it
> > >
> > > src vm: -m xG,memdev=SHARED_RAM -object memory-backend-
> > file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
> > > dst vm: -m xG,memdev=SHARED_RAM -object memory-backend-
> > file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
> >
> > After a second thought, I find adding a backend for nonnuma pc RAM is
> > roundabout way.
> >
> > And we actually have an existing way to add a file-backed RAM: commit
> > c902760fb25f ("Add option to use file backed guest memory"). Basically, this
> > commit adds two options, --mem-path and --mem-prealloc, without specify
> > a backend explicitly.
> >
> > So how about just adding a new option --mem-share to decide if that's a
> > private memory or shared memory? That seems much straightforward way
Above options are legacy (which we can't remove for compat reasons),
their replacement is 'memory-backend-file' backend which has all of
the above including 'share' property.
So just add 'memdev' property to machine and reuse memory-backend-file
with it instead of duplicating functionality in the legacy code.
> > to me; after this change we can migrate like:
> >
> > src vm: -m xG
> > dst vm: -m xG --mem-path xxx --mem-share
Even though it might work for now, that's still invalid configuration
for migration, src side must include the same
"--mem-path xxx --mem-share"
options as dst.
It'd be better to fix management application to start QEMU
properly on SRC side.
> Attach the patch FYI. Look forward to your thoughts.
>
> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> index 31612ca..5eaf367 100644
> --- a/include/sysemu/sysemu.h
> +++ b/include/sysemu/sysemu.h
> @@ -127,6 +127,7 @@ extern bool enable_mlock;
> extern uint8_t qemu_extra_params_fw[2];
> extern QEMUClockType rtc_clock;
> extern const char *mem_path;
> +extern int mem_share;
> extern int mem_prealloc;
>
> #define MAX_NODES 128
> diff --git a/numa.c b/numa.c
> index 7b9c33a..322289f 100644
> --- a/numa.c
> +++ b/numa.c
> @@ -456,7 +456,7 @@ static void allocate_system_memory_nonnuma(MemoryRegion *mr, Object *owner,
> if (mem_path) {
> #ifdef __linux__
> Error *err = NULL;
> - memory_region_init_ram_from_file(mr, owner, name, ram_size, false,
> + memory_region_init_ram_from_file(mr, owner, name, ram_size, mem_share,
> mem_path, &err);
> if (err) {
> error_report_err(err);
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 678181c..c968c53 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -389,6 +389,15 @@ STEXI
> Allocate guest RAM from a temporarily created file in @var{path}.
> ETEXI
>
> +DEF("mem-share", 0, QEMU_OPTION_memshare,
> + "-mem-share make guest memory shareable (use with -mem-path)\n",
> + QEMU_ARCH_ALL)
> +STEXI
> +@item -mem-share
> +@findex -mem-share
> +Make file-backed guest RAM shareable when using -mem-path.
> +ETEXI
> +
> DEF("mem-prealloc", 0, QEMU_OPTION_mem_prealloc,
> "-mem-prealloc preallocate guest memory (use with -mem-path)\n",
> QEMU_ARCH_ALL)
> diff --git a/vl.c b/vl.c
> index 444b750..0ff06c2 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -140,6 +140,7 @@ int display_opengl;
> const char* keyboard_layout = NULL;
> ram_addr_t ram_size;
> const char *mem_path = NULL;
> +int mem_share = 0;
> int mem_prealloc = 0; /* force preallocation of physical target memory */
> bool enable_mlock = false;
> int nb_nics;
> @@ -3395,6 +3396,9 @@ int main(int argc, char **argv, char **envp)
> case QEMU_OPTION_mempath:
> mem_path = optarg;
> break;
> + case QEMU_OPTION_memshare:
> + mem_share = 1;
> + break;
> case QEMU_OPTION_mem_prealloc:
> mem_prealloc = 1;
> break;
next prev parent reply other threads:[~2018-02-26 12:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-05 14:58 [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration Jianfeng Tan
2018-02-05 15:45 ` no-reply
2018-02-05 15:53 ` Paolo Bonzini
2018-02-05 16:12 ` Tan, Jianfeng
2018-02-05 16:19 ` Paolo Bonzini
2018-02-05 16:44 ` Tan, Jianfeng
2018-02-05 16:53 ` Paolo Bonzini
2018-02-05 17:15 ` Igor Mammedov
2018-02-05 17:31 ` Paolo Bonzini
2018-02-07 7:49 ` Tan, Jianfeng
2018-02-07 12:06 ` Igor Mammedov
2018-02-08 1:20 ` Tan, Jianfeng
2018-02-08 9:51 ` Igor Mammedov
2018-02-08 10:18 ` Tan, Jianfeng
2018-02-08 11:30 ` Igor Mammedov
2018-02-24 3:08 ` Tan, Jianfeng
2018-02-24 3:11 ` Tan, Jianfeng
2018-02-26 12:55 ` Igor Mammedov [this message]
2018-02-26 14:43 ` Paolo Bonzini
2018-02-27 4:55 ` Tan, Jianfeng
2018-02-27 4:36 ` Tan, Jianfeng
2018-02-28 15:40 ` Igor Mammedov
2018-02-05 18:44 ` Dr. David Alan Gilbert
2018-02-05 16:12 ` no-reply
2018-02-05 16:29 ` Igor Mammedov
2018-02-05 16:51 ` Tan, Jianfeng
2018-02-05 18:36 ` Dr. David Alan Gilbert
2018-02-06 15:24 ` Igor Mammedov
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=20180226135549.34af5dbf@redhat.com \
--to=imammedo@redhat.com \
--cc=jasowang@redhat.com \
--cc=jianfeng.tan@intel.com \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).