On 5/20/21 7:53 AM, Sean Christopherson wrote:
On Wed, May 19, 2021, Krish Sadhukhan wrote:
Currently, the 'nested_run' statistic counts all guest-entry attempts,
including those that fail during vmentry checks on Intel and during
consistency checks on AMD. Convert this statistic to count only those
guest-entries that make it past these state checks and make it to guest
code. This will tell us the number of guest-entries that actually executed
or tried to execute guest code.
Also, rename this statistic to 'nested_runs' since it is a count.
Signed-off-by: Krish Sadhukhan <Krish.Sadhukhan@xxxxxxxxxx>
Suggested-by: Sean Christopherson <seanjc@xxxxxxxxxx>
I didn't suggest this, or at least I didn't intend to.
The idea behind my v1 patch was actually to eliminate failed attempts of
vmentry but of course I didn't place the counter in the right location.
In v2, I placed it based on your suggestion.
So, the burden of the intention to count only successful vmentries still
falls on me 😁.
My point was that _if_
we want stat.nested_run to count successful VM-Enter then the counter should be
bumped only after VM-Enter succeeds. I did not mean to say that we should
actually do this. As Dongli pointed out[*], there is value in tracking attempts,
and I still don't understand _why_ we care about only counting successful
VM-Enters.
If we count all attempts, failed and successful, the counter won't tell
us if any failed and how many. On the other hand, if we count only
successful attempts, we won't know if there were any failed attempts.
Both ways we miss potentially valuable data, but unless the count of
failures is greatly useful we just count attempts that actually ended up
executing a nested guest.
The other alternative is to provide two counters, 'nested_run_attempts'
to count all attempts and 'nested_runs' to count only successful ones.
FWIW, this misses the case where L1 enters L2 in an inactive state.
[*] ed4a8dae-be99-0d88-a8dd-510afe7cb956@xxxxxxxxxx
