From: Kashyap Chamarthy <kchamart@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, cohuck@redhat.com, dgilbert@redhat.com,
vkuznets@redhat.com
Subject: Re: [PATCH v2] docs/virt/kvm: Document running nested guests
Date: Mon, 27 Apr 2020 12:14:18 +0200 [thread overview]
Message-ID: <20200427101418.GA25403@paraplu> (raw)
In-Reply-To: <c35b6a07-0e5c-fef7-2a39-b0f498eea36c@redhat.com>
On Tue, Apr 21, 2020 at 12:35:21PM +0200, Paolo Bonzini wrote:
> Mostly looks good except for kernel parameters:
[Just noticed this; somehow the KVM e-mails, which I explicitly Cced
myself, aren't arriving in my Inbox.]
> On 20/04/20 13:17, Kashyap Chamarthy wrote:
> > +Enabling "nested" (x86)
> > +-----------------------
> > +
> > +From Linux kernel v4.19 onwards, the ``nested`` KVM parameter is enabled
> > +by default for Intel x86, but *not* for AMD. (Though your Linux
> > +distribution might override this default.)
>
> It is enabled for AMD as well.
Ah, thanks. Will correct.
> > +
> > +If your hardware is sufficiently advanced (Intel Haswell processor or
> > +above which has newer hardware virt extensions), you might want to
> > +enable additional features: "Shadow VMCS (Virtual Machine Control
> > +Structure)", APIC Virtualization on your bare metal host (L0).
> > +Parameters for Intel hosts::
> > +
> > + $ cat /sys/module/kvm_intel/parameters/enable_shadow_vmcs
> > + Y
> > +
> > + $ cat /sys/module/kvm_intel/parameters/enable_apicv
> > + N
> > +
> > + $ cat /sys/module/kvm_intel/parameters/ept
> > + Y
>
>
> These are enabled by default if you have them, on all kernel versions.
> So you may instead tell people to check them (especially
> enable_shadow_vmcs and ept) if their L2 guests run slower.
Noted, will amend.
> >
> > +Starting a nested guest (x86)
> > +-----------------------------
> > +
> > +Once your bare metal host (L0) is configured for nesting, you should be
> > +able to start an L1 guest with::
> > +
> > + $ qemu-kvm -cpu host [...]
> > +
> > +The above will pass through the host CPU's capabilities as-is to the
> > +gues); or for better live migration compatibility, use a named CPU
> > +model supported by QEMU. e.g.::
> > +
> > + $ qemu-kvm -cpu Haswell-noTSX-IBRS,vmx=on
> > +
> > +then the guest hypervisor will subsequently be capable of running a
> > +nested guest with accelerated KVM.
> > +
>
> The latter is only on QEMU 4.2 and newer. Also, you should group by
> architecture and use third-level headings within an architecture.
Okay, will adjust the structure.
Thanks for the review.
--
/kashyap
next prev parent reply other threads:[~2020-04-27 10:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-20 11:17 [PATCH v2] docs/virt/kvm: Document running nested guests Kashyap Chamarthy
2020-04-21 10:35 ` Paolo Bonzini
2020-04-27 10:14 ` Kashyap Chamarthy [this message]
2020-04-22 8:56 ` Cornelia Huck
2020-04-27 15:22 ` Kashyap Chamarthy
2020-04-30 10:25 ` Cornelia Huck
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=20200427101418.GA25403@paraplu \
--to=kchamart@redhat.com \
--cc=cohuck@redhat.com \
--cc=dgilbert@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox