On 8/2/21 9:39 AM, Paolo Bonzini wrote:

On 02/08/21 18:34, Sean Christopherson wrote:

quoted

On Mon, Aug 02, 2021, Paolo Bonzini wrote:

quoted

On 21/06/21 22:43, Krish Sadhukhan wrote:

quoted

With this patch KVM entry and exit tracepoints will
show "guest_mode = 0" if it is a guest and "guest_mode = 1" if it is a
nested guest.

What about adding a "(nested)" suffix for L2, and nothing for L1?

That'd work too, though it would be nice to get vmcx12 printed as 
well so that
it would be possible to determine which L2 is running without having 
to cross-
reference other tracepoints.

Yes, it would be nice but it would also clutter the output a bit.
It's like what we have already in kvm_inj_exception:

        TP_printk("%s (0x%x)",
                  __print_symbolic(__entry->exception, 
kvm_trace_sym_exc),
                  /* FIXME: don't print error_code if not present */
                  __entry->has_error ? __entry->error_code : 0)

It could be done with a trace-cmd plugin, but that creates other 
issues since
it essentially forces the tracepoints to have a stable API.

Paolo

Also, the vmcs/vmcb address is vCPU-specific, so if L2 runs on 10 vCPUs, 
traces will show 10 different addresses for the same L2 and it's not 
convenient on a cloud host where hundreds of L1s and L2s run. IMHO, the 
cleanest solution is if the hardware vendors can provide a UUID space in 
the VMCS/VMCB itself. Today, we can print the UUID of L1 (by getting it 
from QEMU), but there's no way we can find out the one of L2.

OK, for now, I will add "nested" for L2 and nothing for L1.