From: Eduardo Habkost <ehabkost@redhat.com>
To: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: qemu-devel@nongnu.org, Andrea Arcangeli <aarcange@redhat.com>,
paul.c.lai@intel.com, Bandan Das <bsd@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH] x86: host-phys-bits-limit option
Date: Wed, 12 Dec 2018 12:12:33 -0200 [thread overview]
Message-ID: <20181212141233.GS7141@habkost.net> (raw)
In-Reply-To: <20181212090839.iuc5pebm7luitdsk@linux.intel.com>
On Wed, Dec 12, 2018 at 05:08:39PM +0800, Yu Zhang wrote:
> On Tue, Dec 11, 2018 at 05:25:27PM -0200, Eduardo Habkost wrote:
> > Some downstream distributions of QEMU set host-phys-bits=on by
> > default. This worked very well for most use cases, because
> > phys-bits really didn't have huge consequences. The only
> > difference was on the CPUID data seen by guests, and on the
> > handling of reserved bits.
> >
> > This changed in KVM commit 855feb673640 ("KVM: MMU: Add 5 level
> > EPT & Shadow page table support"). Now choosing a large
> > phys-bits value for a VM has bigger impact: it will make KVM use
> > 5-level EPT even when it's not really necessary. This means
> > using the host phys-bits value may not be the best choice.
> >
> > Management software could address this problem by manually
> > configuring phys-bits depending on the size of the VM and the
> > amount of MMIO address space required for hotplug. But this is
> > not trivial to implement.
> >
> > However, there's another workaround that would work for most
> > cases: keep using the host phys-bits value, but only if it's
> > smaller than 48. This patch makes this possible by introducing a
> > new "-cpu" option: "host-phys-bits-limit". Management software
> > or users can make sure they will always use 4-level EPT using:
> > "host-phys-bits=on,host-phys-bits-limit=48".
> >
> > This behavior is still not enabled by default because QEMU
> > doesn't enable host-phys-bits=on by default. But users,
> > management software, or downstream distributions may choose to
> > change their defaults using the new option.
> >
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
>
> Thanks, Eduardo. One question is, should we check host-phys-bits-limit
> against 48? If not, how about we just say in the commit message, that
> the suggested value of host-phys-bits-limit is no bigger than 48 to
> ensure a 4-level EPT? :-)
I'm not sure I understood the question. I tried to document this
at:
| [...] Management software
| or users can make sure they will always use 4-level EPT using:
| "host-phys-bits=on,host-phys-bits-limit=48".
--
Eduardo
next prev parent reply other threads:[~2018-12-12 14:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 19:25 [Qemu-devel] [PATCH] x86: host-phys-bits-limit option Eduardo Habkost
2018-12-12 9:08 ` Yu Zhang
2018-12-12 14:12 ` Eduardo Habkost [this message]
2018-12-13 0:52 ` Yu Zhang
2019-01-07 17:23 ` Eduardo Habkost
2018-12-12 14:08 ` Wainer dos Santos Moschetta
2018-12-12 14:29 ` Eduardo Habkost
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=20181212141233.GS7141@habkost.net \
--to=ehabkost@redhat.com \
--cc=aarcange@redhat.com \
--cc=bsd@redhat.com \
--cc=imammedo@redhat.com \
--cc=paul.c.lai@intel.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=yu.c.zhang@linux.intel.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.