On Thu, May 03, 2018 at 03:48:12PM +0200, Paolo Bonzini wrote: > On 03/05/2018 15:38, Alexander Shishkin wrote: > > On Thu, May 03, 2018 at 02:50:12PM +0200, Paolo Bonzini wrote: > >> On 03/05/2018 14:48, Alexander Shishkin wrote: > >>>> Guest tracing can only be enabled at boot time, because the guest's > >>>> CPUID changes depending on whether it's enabled. And likewise if perf > >>>> record can do system-wide tracing at any time during the guest's > >>>> execution, we need to know it at boot time in order to set the guest CPUID. > >>> > >>> CPUID is immaterial here; the real trick is to disallow the use of PT at > >>> runtime when the host suddenly decides to trace the guest, in such a way > >>> that the guest user is informed that their trace is incomplete due to the > >>> host activity. > >> > >> How do you do that? > > > > Off the top of my head: > > * you don't; > > * you write something to the PT stream; > > * you signal an error via RTIT_STATUS; > > * guest always prevails: host gets PARTIAL records in case of a conflict. > > > >> And you still need the module parameter to decide > >> whether the host is _allowed_ to cause incomplete traces in the guest. > > > > 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. Regards, -- Alex
