On Wed, Feb 24, 2016 at 11:44 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > On 24/02/2016 20:38, Andy Lutomirski wrote: >> If the master clock accurately exposed CLOCK_MONOTONIC_RAW or >> CLOCK_MONOTONIC (I much prefer the latter), then it would be fine >> across suspend/resume. > > Here we already have a conflict... Owen says he prefers the master clock > to expose the (stable) TSC, you say you prefer CLOCK_MONOTONIC. > > I for one _thought_ CLOCK_MONOTONIC would have been my choice, but I'm > not so sure about it and I'm also not sure it's possible to do it > efficiently. I think it should be configurable. > The mult/shift/offset tuple potentially can change every > tick, and it would be bad to do such an update #vms times per tick (or > worse, #vcpus times per tick). If the interface were sane, it would be a single update per tick that would update a data structure that all guests would share. Arguably we ought to expose all three useful clocks (MONOTONIC, MONOTONIC_RAW, and REALTIME) in the same page. The vclock code already does this for MONOTONIC and REALTIME.) Each vm would have a *different* page that had information like the guest-boot-to-monotonic offset. > > Paolo -- Andy Lutomirski AMA Capital Management, LLC -- 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
