On Thu, May 12, 2011 at 8:42 AM, Avi Kivity <a...@redhat.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
