From: Paolo Bonzini <pbonzini@redhat.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>,
"Marcelo Tosatti" <mtosatti@redhat.com>
Cc: kvm-devel <kvm@vger.kernel.org>
Subject: Re: KVM: x86: workaround SuSE's 2.6.16 pvclock vs masterclock issue
Date: Thu, 22 Jan 2015 09:10:13 +0100 [thread overview]
Message-ID: <54C0B065.8070801@redhat.com> (raw)
In-Reply-To: <20150121170033.GB9085@potion.brq.redhat.com>
On 21/01/2015 18:00, Radim Krčmář wrote:
> 2015-01-21 12:16-0200, Marcelo Tosatti:
>> On Wed, Jan 21, 2015 at 03:09:27PM +0100, Radim Krčmář wrote:
>>> 2015-01-20 15:54-0200, Marcelo Tosatti:
>>>> SuSE's 2.6.16 kernel fails to boot if the delta between tsc_timestamp
>>>> and rdtsc is larger than a given threshold:
>>> [...]
>>>> Disable masterclock support (which increases said delta) in case the
>>>> boot vcpu does not use MSR_KVM_SYSTEM_TIME_NEW.
>>>
>>> Why do we care about 2.6.16 bugs in upstream KVM?
>>
>> Because people do use 2.6.16 guests.
>
> (Those people probably won't use 3.19+ host ...
Why not? If you are a cloud provider, you cannot really know what guests
your customer run.
Also, the masterclock support has been in there for a while. It was not
working as well as it could, which is why we noticed it only now, but
still it was broken before as well. 1/5th of a jiffy is a really really
low amount.
>>> MSR_KVM_SYSTEM_TIME is deprecated -- we could remove it now, with
>>> MSR_KVM_WALL_CLOCK (after hiding KVM_FEATURE_CLOCKSOURCE) if we want
>>> to support old guests.
>>
>> What is the benefit of removing support for MSR_KVM_SYSTEM_TIME ?
>
> The maintainability of the code increases. It would look as if we never
> made the mistake with MSR_KVM_SYSTEM_TIME & MSR_KVM_WALL_CLOCK.
> (I like when old code looks as if we wrote it from scratch.)
Everybody does, and everybody obsesses over splitting patches so that
they look as if the code had been split that way from scratch. Heck, I
probably spend over half of my development time inside "git rebase -i".
But it's just not how reality works, and it must show sooner or later.
:) Anyway, it's just two case labels or so (before this patch).
>> Supporting old guests is important.
>
> It comes at a price.
> (Mutually exclusive goals are important as well.)
Marcelo's patch is not too high a price. Is it ugly? Yes. Could it be
any better? No, because the ugliness is not his fault, it's intrinsic
in the problem it solves.
Paolo
next prev parent reply other threads:[~2015-01-22 8:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 17:54 KVM: x86: workaround SuSE's 2.6.16 pvclock vs masterclock issue Marcelo Tosatti
2015-01-20 19:40 ` Paolo Bonzini
2015-01-21 14:09 ` Radim Krčmář
2015-01-21 14:16 ` Marcelo Tosatti
2015-01-21 17:00 ` Radim Krčmář
2015-01-22 1:40 ` Marcelo Tosatti
2015-01-22 13:59 ` Radim Krčmář
2015-01-22 18:12 ` Marcelo Tosatti
2015-01-22 19:33 ` Radim Krčmář
2015-01-22 8:10 ` Paolo Bonzini [this message]
2015-01-22 17:02 ` Radim Krčmář
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54C0B065.8070801@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=rkrcmar@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox