From: Wanpeng Li <wanpeng.li@hotmail.com>
To: Jan Kiszka <jan.kiszka@siemens.com>, Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: nVMX: nested VPID emulation
Date: Wed, 16 Sep 2015 10:36:04 +0800 [thread overview]
Message-ID: <BLU436-SMTP6118AF3609D120263A4AE1805B0@phx.gbl> (raw)
In-Reply-To: <55F8563D.3050905@siemens.com>
On 9/16/15 1:32 AM, Jan Kiszka wrote:
> On 2015-09-15 12:14, Wanpeng Li wrote:
>> On 9/14/15 10:54 PM, Jan Kiszka wrote:
>>> Last but not least: the guest can now easily exhaust the host's pool of
>>> vpid by simply spawning plenty of VCPUs for L2, no? Is this acceptable
>>> or should there be some limit?
>> I reuse the value of vpid02 while vpid12 changed w/ one invvpid in v2,
>> and the scenario which you pointed out can be avoid.
> I cannot yet follow why there is no chance for L1 to consume all vpids
> that the host manages in that single, global bitmap by simply spawning a
> lot of nested VCPUs for some L2. What is enforcing L1 to call nested
> vmclear - apparently the only way, besides destructing nested VCPUs, to
> release such vpids again?
In v2, there is no direct mapping between vpid02 and vpid12, the vpid02
is per-vCPU for L0 and reused while the value of vpid12 is changed w/
one invvpid during nested vmentry. The vpid12 is allocated by L1 for L2,
so it will not influence global bitmap(for vpid01 and vpid02 allocation)
even if spawn a lot of nested vCPUs.
Regards,
Wanpeng Li
next prev parent reply other threads:[~2015-09-16 2:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 12:52 [PATCH] KVM: nVMX: nested VPID emulation Wanpeng Li
2015-09-14 14:54 ` Jan Kiszka
2015-09-15 10:14 ` Wanpeng Li
2015-09-15 17:32 ` Jan Kiszka
2015-09-16 2:36 ` Wanpeng Li [this message]
2015-09-16 5:20 ` Jan Kiszka
2015-09-16 6:10 ` Wanpeng Li
2015-09-14 16:08 ` Bandan Das
2015-09-15 10:18 ` Wanpeng Li
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=BLU436-SMTP6118AF3609D120263A4AE1805B0@phx.gbl \
--to=wanpeng.li@hotmail.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@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 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.