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.
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 rdt
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 i
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 n
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.
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:
> 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 gue
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
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.
> T
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. A
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
> tim
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,
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 difficul
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)
{
15 matches
Mail list logo
