From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
kvm@vger.kernel.org, john cooper <john.cooper@redhat.com>,
avi@redhat.com
Subject: Re: [Qemu-devel] [patch uq/master 2/2] Add option to use file backed guest memory
Date: Sun, 28 Feb 2010 01:28:16 +0000 [thread overview]
Message-ID: <201002280128.16649.paul@codesourcery.com> (raw)
In-Reply-To: <20100224211507.913712224@amt.cnet>
>+ /*
>+ * ftruncate is not supported by hugetlbfs in older
>+ * hosts, so don't bother checking for errors.
>+ * If anything goes wrong with it under other filesystems,
>+ * mmap will fail.
>+ */
>+ if (ftruncate(fd, memory))
>+ perror("ftruncate");
Code does not match comment.
>+ if (asprintf(&filename, "%s/kvm.XXXXXX", path) == -1) {
>+ return NULL;
>+ }
This isn't kvm any more :-)
>+ flags = mem_prealloc ? MAP_POPULATE|MAP_SHARED : MAP_PRIVATE;
Missing spaces round logic operator (plus several other occurrences).
>+static void *file_ram_alloc(ram_addr_t memory, const char *path)
>+{
>+ return NULL;
>+}
Silently ignoring commandline options is bad.
Especially as the other option you added (-mem-prealloc) causes an error if
not supported.
>+ if (kvm_enabled() && !kvm_has_sync_mmu()) {
>+ fprintf(stderr, "kvm: host lacks mmu notifiers, disabling
> -mem-path\n"); + return NULL;
>+ }
Code does not match error message. Users are liable to see this many times.
>+ new_block->host = file_ram_alloc(size, mem_path);
IMHO it would be better to check the mem_path != NULL here, rather that
burying the check in file_ram_alloc.
>+ if (memory < hpagesize) {
>+ return NULL;
>+ }
Ah, so it's actually "allocate memory in $path, if you feel like it". Good job
we aren't relying on this for correctness. At minimum I recommend documenting
this heuristic.
>+ if (!new_block->host) {
> #if defined(TARGET_S390X) && defined(CONFIG_KVM)
>- /* XXX S390 KVM requires the topmost vma of the RAM to be < 256GB */
By my reading this implies -mempath is probably broken on s390 KVM?
>+DEF("mem-path", HAS_ARG, QEMU_OPTION_mempath,
>+ "-mem-path FILE provide backing storage for guest RAM\n")
>+STEXI
>+@item -mem-path @var{path}
>+Allocate guest RAM from a temporarily created file in @var{path}.
>+ETEXI
You should mention that this is only useful when PATH happens to be a linux
hugetlbfs mount.
>+#ifdef MAP_POPULATE
>+ case QEMU_OPTION_mem_prealloc:
>+ mem_prealloc = !mem_prealloc;
>+#endif
This looks highly suspect. Having redundant options toggle the sate seems
like a particularly bad UI.
Paul
WARNING: multiple messages have this Message-ID (diff)
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: john cooper <john.cooper@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
avi@redhat.com, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [patch uq/master 2/2] Add option to use file backed guest memory
Date: Sun, 28 Feb 2010 01:28:16 +0000 [thread overview]
Message-ID: <201002280128.16649.paul@codesourcery.com> (raw)
In-Reply-To: <20100224211507.913712224@amt.cnet>
>+ /*
>+ * ftruncate is not supported by hugetlbfs in older
>+ * hosts, so don't bother checking for errors.
>+ * If anything goes wrong with it under other filesystems,
>+ * mmap will fail.
>+ */
>+ if (ftruncate(fd, memory))
>+ perror("ftruncate");
Code does not match comment.
>+ if (asprintf(&filename, "%s/kvm.XXXXXX", path) == -1) {
>+ return NULL;
>+ }
This isn't kvm any more :-)
>+ flags = mem_prealloc ? MAP_POPULATE|MAP_SHARED : MAP_PRIVATE;
Missing spaces round logic operator (plus several other occurrences).
>+static void *file_ram_alloc(ram_addr_t memory, const char *path)
>+{
>+ return NULL;
>+}
Silently ignoring commandline options is bad.
Especially as the other option you added (-mem-prealloc) causes an error if
not supported.
>+ if (kvm_enabled() && !kvm_has_sync_mmu()) {
>+ fprintf(stderr, "kvm: host lacks mmu notifiers, disabling
> -mem-path\n"); + return NULL;
>+ }
Code does not match error message. Users are liable to see this many times.
>+ new_block->host = file_ram_alloc(size, mem_path);
IMHO it would be better to check the mem_path != NULL here, rather that
burying the check in file_ram_alloc.
>+ if (memory < hpagesize) {
>+ return NULL;
>+ }
Ah, so it's actually "allocate memory in $path, if you feel like it". Good job
we aren't relying on this for correctness. At minimum I recommend documenting
this heuristic.
>+ if (!new_block->host) {
> #if defined(TARGET_S390X) && defined(CONFIG_KVM)
>- /* XXX S390 KVM requires the topmost vma of the RAM to be < 256GB */
By my reading this implies -mempath is probably broken on s390 KVM?
>+DEF("mem-path", HAS_ARG, QEMU_OPTION_mempath,
>+ "-mem-path FILE provide backing storage for guest RAM\n")
>+STEXI
>+@item -mem-path @var{path}
>+Allocate guest RAM from a temporarily created file in @var{path}.
>+ETEXI
You should mention that this is only useful when PATH happens to be a linux
hugetlbfs mount.
>+#ifdef MAP_POPULATE
>+ case QEMU_OPTION_mem_prealloc:
>+ mem_prealloc = !mem_prealloc;
>+#endif
This looks highly suspect. Having redundant options toggle the sate seems
like a particularly bad UI.
Paul
next prev parent reply other threads:[~2010-02-28 1:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-24 21:11 [patch uq/master 0/2] port qemu-kvm's -mem-path and -mem-prealloc to qemu Marcelo Tosatti
2010-02-24 21:11 ` [Qemu-devel] " Marcelo Tosatti
2010-02-24 21:11 ` [patch uq/master 1/2] Allocate memory below 4GB as one chunk Marcelo Tosatti
2010-02-24 21:11 ` [Qemu-devel] " Marcelo Tosatti
2010-02-25 13:33 ` Avi Kivity
2010-02-25 13:33 ` [Qemu-devel] " Avi Kivity
2010-02-24 21:11 ` [patch uq/master 2/2] Add option to use file backed guest memory Marcelo Tosatti
2010-02-24 21:11 ` [Qemu-devel] " Marcelo Tosatti
2010-02-28 1:28 ` Paul Brook [this message]
2010-02-28 1:28 ` Paul Brook
2010-03-01 23:25 ` Marcelo Tosatti
2010-03-01 23:25 ` Marcelo Tosatti
2010-03-01 23:32 ` Marcelo Tosatti
2010-03-01 23:32 ` Marcelo Tosatti
2010-02-25 13:32 ` [patch uq/master 0/2] port qemu-kvm's -mem-path and -mem-prealloc to qemu Avi Kivity
2010-02-25 13:32 ` [Qemu-devel] " Avi Kivity
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=201002280128.16649.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=avi@redhat.com \
--cc=john.cooper@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@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 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.