kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Krish Sadhukhan <krish.sadhukhan@oracle.com>
Cc: Jim Mattson <jmattson@google.com>, kvm list <kvm@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 2/3] KVM: nVMX: Add a new VCPU statistic to show if VCPU is running nested guest
Date: Wed, 12 May 2021 18:19:15 +0000	[thread overview]
Message-ID: <YJwcI+X5ToPleBh8@google.com> (raw)
In-Reply-To: <c5c4a9d2-73b5-69eb-58ee-c52df4c2ff18@oracle.com>

On Wed, May 12, 2021, Krish Sadhukhan wrote:
> 
> On 5/12/21 9:01 AM, Jim Mattson wrote:
> > On Tue, May 11, 2021 at 7:37 PM Krish Sadhukhan
> > <krish.sadhukhan@oracle.com> wrote:
> > > Add the following per-VCPU statistic to KVM debugfs to show if a given
> > > VCPU is running a nested guest:
> > > 
> > >          nested_guest_running
> > > 
> > > Also add this as a per-VM statistic to KVM debugfs to show the total number
> > > of VCPUs running a nested guest in a given VM.
> > > 
> > > Signed-off-by: Krish Sadhukhan <Krish.Sadhukhan@oracle.com>
> > This is fine, but I don't really see its usefulness. OTOH, one
> 
> Two potential uses:
> 
>     1. If Live Migration of L2 guests is broken/buggy, this can be used to
> determine a safer time to trigger Live Migration of L1 guests.

This seems tenuous.  The stats are inherently racy, so userspace would still need
to check for "guest mode" after retrieving state.  And wouldn't you want to wait
until L1 turns VMX/SVM _off_?  If migrating L2 is broken, simply waiting until L2
exits likely isn't going to help all that much.

>     2. This can be used to create a time-graph of the load of L1 and L2 in a
> given VM as well across the host.

Hrm, I like the idea of being able to observe how much time a vCPU is spending
in L1 vs. L2, but cross-referencing guest time with "in L2" seems difficult
and error prone.  I wonder if we can do better, i.e. explicitly track L1 vs. L2+
usage.  I think that would also grant Jim's wish of being able to more precisely
track nested virtualization utilization.

> > statistic I would really like to see is how many vCPUs have *ever* run
> > a nested guest.

  parent reply	other threads:[~2021-05-12 19:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12  1:47 [PATCH 0/3] KVM: nVMX: Add more statistics to KVM debugfs Krish Sadhukhan
2021-05-12  1:47 ` [PATCH 1/3] KVM: nVMX: Move 'nested_run' counter to enter_guest_mode() Krish Sadhukhan
2021-05-12 18:30   ` Sean Christopherson
2021-05-13 16:02     ` Dongli Zhang
2021-05-12  1:47 ` [PATCH 2/3] KVM: nVMX: Add a new VCPU statistic to show if VCPU is running nested guest Krish Sadhukhan
2021-05-12 16:01   ` Jim Mattson
2021-05-12 17:56     ` Krish Sadhukhan
2021-05-12 17:59       ` Jim Mattson
2021-05-12 18:19       ` Sean Christopherson [this message]
2021-05-12  1:47 ` [PATCH 3/3] KVM: x86: Add a new VM statistic to show number of VCPUs created in a given VM Krish Sadhukhan

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=YJwcI+X5ToPleBh8@google.com \
    --to=seanjc@google.com \
    --cc=jmattson@google.com \
    --cc=krish.sadhukhan@oracle.com \
    --cc=kvm@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).