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?
#ifndef _PV_PVCLOCK_H_
#define _PV_PVCLOCK_H_
struct pvclock_vcpu_time_info {
volatile uint32_t version;
volatile uint32_t pad1;
volatile uint64_t tsc_timestamp;
volatile uint64_t system_time;
volatile uint32_t tsc_to_system_mul;
volatile int8_t tsc_shift;
volatile uint8_t flags;
volatile uint8_t pad2[2];
} __packed;
struct pvclock_wall_clock {
volatile uint32_t version;
volatile uint32_t sec;
volatile uint32_t nsec;
} __packed;
#endif /* _PV_PVCLOCK_H_ */
