[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <270eb55a-b033-f2f6-1cbe-76953079da27@redhat.com>
Date: Fri, 4 May 2018 23:52:48 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc: Luwei Kang <luwei.kang@...el.com>, kvm@...r.kernel.org,
tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
x86@...nel.org, rkrcmar@...hat.com, linux-kernel@...r.kernel.org,
joro@...tes.org, peterz@...radead.org, chao.p.peng@...ux.intel.com
Subject: Re: [PATCH v7 06/13] KVM: x86: Add Intel Processor Trace
virtualization mode
On 04/05/2018 12:38, Alexander Shishkin wrote:
>>> Or rather a parameter to decide who wins in case both host and guest want
>>> to trace the guest. That's arguably better than having different versions of
>>> PT in the guest depending on a module parameter setting.
>> It's not different versions; it's having PT vs. not having PT at all. I
>> don't really see it as a big issue. The nice thing about this series is
>> that the interactions between PT code and KVM code are minimal.
> Unfortunately, it gets it wrong. Like I just said in another email, if you
> switch off host's PT, you need to let them know, which this patchset doesn't
> do. And when it does, it would be the same amount of interaction with PT
> code as what would be required to get the dynamic guest PT right.
Two issues:
1) Is there a fast (10 clock cycles, better if less) way for KVM to know
"PT is enabled on the host", or a callback that KVM can register when
e.g. RTIT_CTL is written?
2) We'd have to write trace records into the guest. That does not sound
that easy. Does it entail parsing the ToPA and all that?
Thanks,
Paolo
Powered by blists - more mailing lists