On 03/13/2012 12:58 PM, Davidlohr Bueso wrote: > On Mon, 2012-03-12 at 12:34 +0200, Avi Kivity wrote: > > On 03/12/2012 01:29 PM, Davidlohr Bueso wrote: > > > On Mon, 2012-03-12 at 10:22 +0200, Avi Kivity wrote: > > > > On 03/11/2012 05:57 PM, Davidlohr Bueso wrote: > > > > > From: Davidlohr Bueso <dave@xxxxxxx> > > > > > > > > > > Add a new tracepoint for vpid allocation and freeing associated to all vCPUs. > > > > > > > > > > > > > Why? > > > > > > > > > > We have been using this tracepoint for some time now to help debug vpids > > > and simulating tagged TLB behavior and performance. This gets to be non > > > trivial when working with large amounts of guests and vCPUs. > > > > I don't follow. Can you give an example of when this tracepoint would > > be useful? > > > > For example when running lots of guests with many different hardware > configurations (ept on/off, vpid on/off) I trace what vcpu has or > doesn't have a corresponding vpid associated. Perhaps this is more > useful for experimental things than actual KVM development. So it seems. Tracepoints should be useful for production deployments, not development. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
