On 17 June 2017 at 14:17, Jonathan Matthew <jonat...@d14n.org> wrote: > > On Fri, Jun 16, 2017 at 01:19:02PM +0200, Mike Belopuhov wrote: > > On Fri, Jun 16, 2017 at 10:25 +0200, Mike Belopuhov wrote: > > > I don't know if it's a good idea to depend on Xen's > > > definition of vcpu_time_info. I think I have factored > > > it out into the pvclock_time_info and put it into the > > > pvclockvar.h or something like that. And then made Xen > > > use those definitions instead of its own. Dunno what's > > > the best course of action here. > > > > > > > This is what I would like to use. I've stripped the API > > part, but we can add it as well. I don't believe this > > file requires a specific license since there's a handful > > of pvclock header files out there implementing a common > > interface so a person committing such a file can add his > > own copyright. Opinions? > > Looks good to me. Can we put the #defines for flag bits in there too? > > #define PVCLOCK_FLAG_TSC_STABLE_BIT (1 << 0) > #define PVCLOCK_FLAG_GUEST_STOPPED (1 << 1) > > As far as I can tell, xen doesn't use these, but Linux handles them in its > common pvclock code anyway. >
Sure, go for it.
