Gerd Hoffmann wrote:
Glauber Costa wrote:
Gerd Hoffmann wrote:
Jeremy Fitzhardinge wrote:
Xen could change the parameters in the instant after
get_time_values(). That change could be as a result of
suspend-resume, so the parameters
and the tsc could be wildly different.
Ah, ok, forgot the
Glauber Costa wrote:
Gerd Hoffmann wrote:
Jeremy Fitzhardinge wrote:
Xen could change the parameters in the instant after
get_time_values(). That change could be as a result of
suspend-resume, so the parameters
and the tsc could be wildly different.
Ah, ok, forgot the rdtsc in the picture.
Gerd Hoffmann wrote:
Jeremy Fitzhardinge wrote:
Xen could change the parameters in the instant after get_time_values().
That change could be as a result of suspend-resume, so the parameters
and the tsc could be wildly different.
Ah, ok, forgot the rdtsc in the picture. With that in mind I
Jeremy Fitzhardinge wrote:
Gerd Hoffmann wrote:
I'm looking at the guest side of the issue right now, trying to identify
common code, and while doing so noticed that xen does the
version-check-loop in both get_time_values_from_xen(void) and
xen_clocksource_read(void), and I can't see any
Gerd Hoffmann wrote:
Hmm, I somehow fail to see a case where it could be non-atomic ...
get_time_values() copies a consistent snapshot, thus
xen_clocksource_read() doesn't race against xen updating the fields.
The snapshot is in a per-cpu variable, thus it doesn't race against
other guest
Jeremy Fitzhardinge wrote:
Xen could change the parameters in the instant after get_time_values().
That change could be as a result of suspend-resume, so the parameters
and the tsc could be wildly different.
Ah, ok, forgot the rdtsc in the picture. With that in mind I fully
agree that the
Gerd Hoffmann wrote:
Jeremy Fitzhardinge wrote:
Xen could change the parameters in the instant after get_time_values().
That change could be as a result of suspend-resume, so the parameters
and the tsc could be wildly different.
Ah, ok, forgot the rdtsc in the picture. With that
Jeremy Fitzhardinge wrote:
Gerd Hoffmann wrote:
Not really. There are only two calls, one in clocksource_read() and one
in the init path. The later is superfluous I think because
clocksource_read() is the only user of the shadowed time info.
Hm. It doesn't look like shadow_time needs to
Jeremy Fitzhardinge wrote:
Gerd Hoffmann wrote:
Wall clock is off a few hours though. Oops.
I think the way wall clock and system clock work together in xen (Jeremy
correct me if I'm wrong) is that the wall clock specifies the point in
time where the system clock started going. As kvm
Gerd Hoffmann wrote:
I'm looking at the guest side of the issue right now, trying to identify
common code, and while doing so noticed that xen does the
version-check-loop in both get_time_values_from_xen(void) and
xen_clocksource_read(void), and I can't see any obvious reason for that.
The
Hi,
Tried to use kvmclock with xenner and noticed that the kvmclock
(MSR_KVM_SYSTEM_TIME msr) is incompatible with xen.
kvm guests do this to translate the tsc delta into nsecs:
#define get_clock(cpu, field) per_cpu(hv_clock, cpu).field
static inline u64 kvm_get_delta(u64 last_tsc)
Gerd Hoffmann wrote:
Hi,
Tried to use kvmclock with xenner and noticed that the kvmclock
(MSR_KVM_SYSTEM_TIME msr) is incompatible with xen.
Patches are welcome, especially as kvmclock isn't merged yet, so there
are no backward compatibility issues.
--
Any sufficiently difficult bug
Avi Kivity wrote:
Gerd Hoffmann wrote:
Hi,
Tried to use kvmclock with xenner and noticed that the kvmclock
(MSR_KVM_SYSTEM_TIME msr) is incompatible with xen.
Patches are welcome, especially as kvmclock isn't merged yet, so there
are no backward compatibility issues.
Great, so I'll
Gerd Hoffmann wrote:
Wall clock is off a few hours though. Oops.
I think the way wall clock and system clock work together in xen (Jeremy
correct me if I'm wrong) is that the wall clock specifies the point in
time where the system clock started going. As kvm fills in host system
time
Gerd Hoffmann wrote:
Wall clock is off a few hours though. Oops.
I think the way wall clock and system clock work together in xen (Jeremy
correct me if I'm wrong) is that the wall clock specifies the point in
time where the system clock started going. As kvm fills in host system
time into
15 matches
Mail list logo
