On Thu, May 12, 2011 at 8:42 AM, Avi Kivity <avi@xxxxxxxxxx> wrote: > > On 05/12/2011 06:39 PM, Dhaval Giani wrote: >> >> > >> > I think that one hypercall per trace is too expensive. Tracing is meant to >> > be lightweight! I think the guest can log to a buffer, which is flushed on >> > overflow or when a vmexit occurs. That gives us automatic serialization >> > between a vcpu and the cpu it runs on, but not between a vcpu and a >> > different host cpu. >> > >> >> hmm. So, basically, log all of these events, and then send them to the >> host either on an exit, or when your buffer fills up. There is one >> problem with approach though. One of the reasons I wanted this >> approach was beacuse i wanted to co-relate the guest and the host >> times. (which is why I kept is synchronous). I lose out that >> information with what you say. However I see your point about the >> overhead. I will think about this a bit more. > > You might use kvmclock to get a zero-exit (but not zero-cost) time which can be correlated. > > Another option is to use xadd on a shared memory area to have a global counter incremented. However that can be slow on large machines, and is hard to do securely with multiple guests. If the guest puts guest TSC into the buffer with each event, KVM can convert guest->host time when it drains the buffers on the next vmexit. That's enough information to do an offline correlation of guest and host events. -- 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
