qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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;

  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).