[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160316225936.GE20310@potion.brq.redhat.com>
Date: Wed, 16 Mar 2016 23:59:36 +0100
From: Radim Krcmar <rkrcmar@...hat.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
Marcelo Tosatti <mtosatti@...hat.com>,
Paolo Bonzini <pbonzini@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
kvm list <kvm@...r.kernel.org>, Alexander Graf <agraf@...e.de>
Subject: Re: [PATCH 1/5] x86/kvm: On KVM re-enable (e.g. after suspend),
update clocks
2016-03-16 15:15-0700, Andy Lutomirski:
> On Wed, Mar 16, 2016 at 3:06 PM, Radim Krcmar <rkrcmar@...hat.com> wrote:
>> Guest TSC is going to jump backward with this patch, which would make
>> the guest think that a lot of cycles passed. This has no bearing on
>> guest timekeeping, because the guest shouldn't be using raw TSC.
>> If we wanted to do something though, there are at least two options:
>> 1) Fake that TSC continued at roughly its specified rate: compute how
>> many cycles could have elapsed while the CPU was suspended (using
>> host time before/after suspend and guest TSC frequency) and adjust
>> guest TSC.
>> 2) Resume guest TSC at its last cycle before suspend.
>> (Roughly what KVM does now.)
>>
>> What are your opinions on TSC faking?
>
> I'd suggest restarting it wherever it left off, because it's simpler.
> If there was a CLOCK_BOOT_RAW, you could try to track it, but I'm not
> sure that such a thing exists.
CLOCK_MONOTONIC_RAW can count in suspend, so CLOCK_BOOT_RAW would be a
conditional alias and it probably doesn't exist because of that.
> FWIW, if you ever intend to support ART ("always running timer")
> passthrough, this is going to be a giant clusterfsck. Good luck. I
> haven't gotten a straight answer as to what hardware actually supports
> that thing, so even testing isn't no easy.
Hm, AR TSC would be best handled by doing nothing ... dropping the
faking logic just became tempting.
>> ---
>> Btw. I'll be spending some days to decipher kvmclock, so I'd also fix
>> the masterclock+suspend issue, if you don't mind ... So far, I don't
>> even see a reason to update kvmclock on kvm_arch_hardware_enable().
>> Suspend is a condition that we want to handle, so kvm_resume would be a
>> better place, but we handle suspend only because TSC and timekeeping has
>> changed, so I think that the right place is in their event notifiers.
>
> I'd be glad to try to review things. Please cc me.
Ok.
> One of the Xen people pointed me at the MS Viridian spec for handling
> TSC rate changes on migration to or from hosts that don't support TSC
> scaling. I wonder if KVM could use the same technique or even the
> same API.
The TSC frequency MSR is read-only in Xen, so I guess it's equivalent to
pvclock. I'll take a deeper look, thanks for pointers.
Powered by blists - more mailing lists