From: Nadav Har'El <nyh@math.technion.ac.il>
To: Gianluca Cecchi <gianluca.cecchi@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: nested virtualization on Intel and needed cpu flags to pass
Date: Wed, 23 Nov 2011 13:01:47 +0200 [thread overview]
Message-ID: <20111123110147.GA28778@fermat.math.technion.ac.il> (raw)
In-Reply-To: <CAG2kNCweZ3nT+bFBR9fxBMJiYr4cY4jK6LpPNAYoGNcrm4j_wg@mail.gmail.com>
On Tue, Nov 22, 2011, Gianluca Cecchi wrote about "nested virtualization on Intel and needed cpu flags to pass":
> I'm going to test nested virtualization on Intel with Fedora 16 host.
>...
> [root at f16 ~]# uname -r
> 3.1.1-2.fc16.x86_64
This Linux version indeed has nested VMX, while
> # uname -r
> 2.6.40.6-0.fc15.x86_64
doesn't.
> Based on docs, the "nested" option is disabled by default on Intel
Indeed. You need to load the kvm_intel module with the "nested=1"
option. You also need to tell qemu that the emulated CPU will advertise
VMX - the simplest way to do this is with "-cpu host" option to qemu.
It seems you did all of this correctly.
> Preliminary results are not so good.
> I created an F16 guest (f16vm), with default options
>..
> Inside the guest I create a windows xp with default values proposed by
>..
> Until now not able to complete installation
Unfortunately, this is a known bug - which I promised to work on, but
haven't yet got around to :(
nested-vmx.txt explictly lists under "known limitations" that: "The
current code supports running Linux guests under KVM guests."
> more tests to come with newer kernel 3.1.1-2.fc16.x86_64
> But before proceeding, probably I need to adjust particular features
> to enable/disable about
> cpu to pass to f16vm guest...
I don't think this is the problem. The underlying problem is that the
VMX spec is very complex, and ideally nested VMX should correctly emulate
each and every bit and each and every corner of it. Because all our
testing was done with KVM L1s and Linux L2s, all the paths that get
exercised in that case were tested and their bugs ironed out - but it is
possible that Windows L2s end up excercising slightly different code
paths that still have bugs, and those need to be fixed.
Unfortunately, I doubt a newer kernel will solve your problem. I think
there are genuine bugs that will have to be fixed.
> What are current advises about cpu flags to pass to optimally use
> nested virtualization with intel at this time?
I don't think there is any such guidelines. The only thing you really
need is "-cpu qemu64,+vmx" (replace qemu64 by whatever you want) to
advertise the exisance of VMX.
--
Nadav Har'El | Wednesday, Nov 23 2011,
nyh@math.technion.ac.il |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |When you lose, don't lose the lesson.
http://nadav.harel.org.il |
next prev parent reply other threads:[~2011-11-23 11:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-22 16:52 nested virtualization on Intel and needed cpu flags to pass Gianluca Cecchi
2011-11-23 11:01 ` Nadav Har'El [this message]
2011-11-24 15:05 ` Gianluca Cecchi
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=20111123110147.GA28778@fermat.math.technion.ac.il \
--to=nyh@math.technion.ac.il \
--cc=gianluca.cecchi@gmail.com \
--cc=kvm@vger.kernel.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