[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r2rw2v8x.fsf@vitty.brq.redhat.com>
Date: Fri, 15 Dec 2017 10:30:54 +0100
From: Vitaly Kuznetsov <vkuznets@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>
Cc: kvm@...r.kernel.org, x86@...nel.org,
Radim Krčmář <rkrcmar@...hat.com>,
"K. Y. Srinivasan" <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
"Michael Kelley \(EOSG\)" <Michael.H.Kelley@...rosoft.com>,
Andy Lutomirski <luto@...nel.org>,
Mohammed Gamal <mmorsy@...hat.com>,
Cathy Avery <cavery@...hat.com>,
Roman Kagan <rkagan@...tuozzo.com>,
linux-kernel@...r.kernel.org, devel@...uxdriverproject.org
Subject: Re: [PATCH v2 0/7] x86/kvm/hyperv: stable clocksorce for L2 guests when running nested KVM on Hyper-V
Paolo Bonzini <pbonzini@...hat.com> writes:
> On 13/12/2017 16:09, Vitaly Kuznetsov wrote:
>> Currently, KVM passes PVCLOCK_TSC_STABLE_BIT to its guests when running in
>> so called 'masterclock' mode and this is only possible when the clocksource
>> on the host is TSC. When running nested on Hyper-V we're using a different
>> clocksource in L1 (Hyper-V TSC Page) which can actually be used for
>> masterclock. This series brings the required support.
>>
>> Making KVM work with TSC page clocksource is relatively easy, it is done in
>> PATCH 5 of the series. All the rest is required to support L1 migration
> ^^^^^^^
>
> Patch 6. :)
>
Off-by-one :-)
>> when TSC frequency changes, we use a special feature from Hyper-V to do
>> the job.
>
> Patches 5-7 are
>
> Acked-by: Paolo Bonzini <pbonzini@...hat.com>
>
Thanks!
> I would appreciate if the Hyper-V folks can provide a topic branch to be
> merged in both HV and KVM trees.
>
There's no such thing as Hyper-V tree, patches are usually getting
merged through 'tip' tree when the majority of changes go to arch/x86 or
Greg's char-misc tree when changes are drivers/hv heavy (+ net, scsi,
pci, hid, ... trees for individual drivers).
In this particular case the series is x86-heavy and I believe it should
go through x86 'tip' tree.
Thomas, Ingo, Peter, could you please take a look? Thanks!
--
Vitaly
Powered by blists - more mailing lists