Hi Marc, Paolo, On Wed, Sep 22, 2021 at 8:37 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 22/09/21 13:22, Marc Zyngier wrote: > > Frankly, this is a job for BPF and the tracing subsystem, not for some > > hardcoded syndrome accounting. It would allow to extract meaningful > > information, prevent bloat, and crucially make it optional. Even empty > > trace points like the ones used in the scheduler would be infinitely > > better than this (load your own module that hooks into these trace > > points, expose the data you want, any way you want). > > I agree. I had left out for later the similar series you had for x86, > but I felt the same as Marc; even just counting the number of > occurrences of each exit reason is a nontrivial amount of memory to > spend on each vCPU. > > Paolo > Thanks for the feedback about this. It is actually kind of what I expected. The correct way is to add valuable h/w exit reasons which have been verified useful for debugging and monitoring purposes instead of exposing all of them blindly. Will have an internal discussion about the historical reason why those are needed in the first place and to see if the reason still exists. Jing _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
