Re: [libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

On Tue, Feb 04, 2014 at 04:42:02PM +0000, Daniel P. Berrange wrote: > On Tue, Feb 04, 2014 at 11:32:47AM -0500, Marcelo Tosatti wrote: > > > > Add an element named "strict-hugepages" to control whether to > > refuse guest initialization in case hugepage allocation cannot > > be performed. > > > > Signed-off-by: Marcelo Tosatti <mtosatti(a)redhat.com&gt; > > > > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in > > index ff50214..e79f5e6 100644 > > --- a/docs/formatdomain.html.in > > +++ b/docs/formatdomain.html.in > > @@ -632,6 +632,9 @@ > > <dt><code>hugepages</code></dt> > > <dd>This tells the hypervisor that the guest should have its memory > > allocated using hugepages instead of the normal native page size.</dd> > > + <dt><code>strict-hugepages</code></dt> > > + <dd>This tells the hypervisor that the guest should refuse to start > > + in case of failure to allocate guest memory with hugepages</dd> > > Huh, we already supply the -mem-prealloc command line flag alongside > the -mem-path flag which should cause QEMU to exit if it cannot allocate > all memory upfront. -mem-path path Allocate guest RAM from a temporarily created file in path. -mem-prealloc Preallocate memory when using -mem-path. "should cause QEMU to exit if it cannot allocate all memory upfront" => no it does not. See more below.

> libvirt to the private implementation detail of QEMU's backing file Right. I am going to add a comment to QEMU saying libvirt interprets the string (so that changing it breaks libvirt). Other tools already do this.

> naming. On top of which I don't see why we need this when we're already > setting -mem-prealloc to enforce exactly this. Because there is no guarantee with -mem-prealloc. For instance, if the hugepage path is not actually hugetlbfs backed, QEMU falls back to malloc().