On 04/28/2018 11:09 AM, Arnd Bergmann wrote:
On Sat, Apr 28, 2018 at 12:21 AM, Joao Martins joao.m.martins@oracle.com wrote:
On 04/27/2018 09:13 PM, Arnd Bergmann wrote:
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c index 761f6af6efa5..637982efecd8 100644 --- a/arch/x86/kernel/pvclock.c +++ b/arch/x86/kernel/pvclock.c @@ -123,28 +123,35 @@ u64 pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
void pvclock_read_wallclock(struct pvclock_wall_clock *wall_clock, struct pvclock_vcpu_time_info *vcpu_time,
struct timespec *ts)
struct timespec64 *ts){ u32 version; u64 delta;
struct timespec now;
struct timespec64 now; /* get wallclock at system boot */ do { version = wall_clock->version; rmb(); /* fetch version before time *//** Note: wall_clock->sec is a u32 value, so it can* only store dates between 1970 and 2106. To allow* times beyond that, we need to create a new hypercall* interface with an extended pvclock_wall_clock structure* like ARM has.*/ now.tv_sec = wall_clock->sec;IIUC the interface you're probably speaking about is common to both ARM and x86 on Xen[*] (since Xen 4.6) i.e.
now.tv_sec = ((uint64_t)s->wc_sec_hi << 32) | s->wc_sec;s representing struct shared_info like on ARM (there's a 32-bit hole where wc_sec_hi is placed on x86_64/ARM). Except on x86 32-bit guests wc_sec_hi is located elsewhere.
Joao[*] https://xenbits.xen.org/docs/4.6-testing/hypercall/x86_64/include,public,xen...
Ah, good. How portable is that? Will it do the right thing (i.e. guarantee to have zeroes on the upper half, or the epoch if supported) on all versions of both KVM and Xen, or do we need an additional check in there?
The whole shared info page is zeroed out by Xen when allocated, so on unsupported platforms that includes the upper half. But I don't know if this is considered ABI or not. FWIW, the oldest release (2.0) has that behavior.
But this is Xen that I'm speaking about; KVM doesn't support this IIUC.
On KVM, there's HC_CLOCK_PAIRING hypercall or else *maybe* host could just write wc_sec_hi at the end of the wall_clock struct (with the current MSR) and given that it's (PAGE_SIZE aligned) guest memory, guest could always keep it zeroed out for unsupported platforms (that won't write more than 12bytes).
I'd suggest leaving the implementation of that to a follow-up patch that you can add once my patch is merged.
/nods
Joao