From: Paolo Bonzini <pbonzini@redhat.com>
To: Jim Mattson <jmattson@google.com>
Cc: "Luiz Capitulino" <lcapitulino@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
"Radim Krčmář" <rkrcmar@redhat.com>,
rostedt@goodmis.org, mhiramat@kernel.org, mtosatti@redhat.com
Subject: Re: [PATCH 2/6] kvm: x86: drop read_tsc_offset()
Date: Wed, 21 Sep 2016 17:22:14 +0200 [thread overview]
Message-ID: <6d755392-d0f7-078f-8db2-b6539846d709@redhat.com> (raw)
In-Reply-To: <CALMp9eR4adqGgx5pzqr6Dw+0cykUxG7fGzx+=CdyGdg+frD-FA@mail.gmail.com>
On 21/09/2016 17:19, Jim Mattson wrote:
> Doesn't that assume you can run the merge program in L1?
You only need the TSC offset, but we should make sure that L0
tracepoints contain enough information to figure out the L0->L2 TSC
offsets (they are the values in VMCS02).
That said, how would you get the trace from L1 if you don't have access
to it?
Paolo
> On Mon, Sep 19, 2016 at 10:37 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>>
>> On 20/09/2016 00:18, Jim Mattson wrote:
>>> Hmmm. Yes, I think it does. With this patch series,
>>> vcpu->arch.tsc_offset appears to contain L1's TSC offset (perhaps
>>> making vmx->nested.vmcs01_tsc_offset redundant).
>>>
>>> However, this unfortunately limits the newly added functionality to
>>> merging host and *L1* guest traces. It doesn't work with L2 (or
>>> deeper) guests. Or perhaps I'm missing something?
>>
>> You can merge L1/L2 first and then host/L1.
>>
>> Paolo
next prev parent reply other threads:[~2016-09-21 15:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-16 14:27 [PATCH v2 0/6] kvm: x86: export TSC information to user-space Luiz Capitulino
2016-09-16 14:27 ` [PATCH 1/6] kvm: x86: add tsc_offset field to struct kvm_vcpu_arch Luiz Capitulino
2016-09-16 14:27 ` [PATCH 2/6] kvm: x86: drop read_tsc_offset() Luiz Capitulino
2016-09-19 15:30 ` Jim Mattson
2016-09-19 15:34 ` Paolo Bonzini
2016-09-19 22:18 ` Jim Mattson
2016-09-20 5:37 ` Paolo Bonzini
2016-09-21 15:19 ` Jim Mattson
2016-09-21 15:22 ` Paolo Bonzini [this message]
2016-09-21 15:31 ` Jim Mattson
2016-09-16 14:27 ` [PATCH 3/6] kvm: kvm_destroy_vm_debugfs(): check debugfs_stat_data pointer Luiz Capitulino
2016-09-16 14:27 ` [PATCH 4/6] kvm: add stubs for arch specific debugfs support Luiz Capitulino
2016-09-16 14:27 ` [PATCH 5/6] kvm: create per-vcpu dirs in debugfs Luiz Capitulino
2016-09-16 14:27 ` [PATCH 6/6] kvm: x86: export TSC information to user-space Luiz Capitulino
2016-09-16 14:56 ` [PATCH v2 0/6] " Paolo Bonzini
2016-09-16 14:59 ` Luiz Capitulino
2016-09-16 14:59 ` Paolo Bonzini
2016-09-16 15:11 ` Luiz Capitulino
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=6d755392-d0f7-078f-8db2-b6539846d709@redhat.com \
--to=pbonzini@redhat.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=lcapitulino@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mtosatti@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=rostedt@goodmis.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
all inboxes | Powered by JetHome®