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.
>
>
> #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_ */
