public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Vadim Rozenfeld <vrozenfe@redhat.com>
To: Peter Lieven <pl@dlhnet.de>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	kvm@vger.kernel.org, gleb@redhat.com, pl@dlh.net
Subject: Re: [RFC PATCH v2 2/2] add support for Hyper-V invariant TSC
Date: Thu, 23 May 2013 08:54:19 -0400 (EDT)	[thread overview]
Message-ID: <1350542924.6451148.1369313659560.JavaMail.root@redhat.com> (raw)
In-Reply-To: <519E0F1E.2040409@dlhnet.de>



----- Original Message -----
From: "Peter Lieven" <pl@dlhnet.de>
To: "Vadim Rozenfeld" <vrozenfe@redhat.com>
Cc: "Marcelo Tosatti" <mtosatti@redhat.com>, kvm@vger.kernel.org, gleb@redhat.com, pl@dlh.net
Sent: Thursday, May 23, 2013 10:44:14 PM
Subject: Re: [RFC PATCH v2 2/2] add support for Hyper-V invariant TSC

On 23.05.2013 14:33, Vadim Rozenfeld wrote:
>
>
> ----- Original Message -----
> From: "Peter Lieven" <pl@dlhnet.de>
> To: "Marcelo Tosatti" <mtosatti@redhat.com>
> Cc: "Vadim Rozenfeld" <vrozenfe@redhat.com>, kvm@vger.kernel.org, gleb@redhat.com, pl@dlh.net
> Sent: Thursday, May 23, 2013 4:18:55 PM
> Subject: Re: [RFC PATCH v2 2/2] add support for Hyper-V invariant TSC
>
> On 22.05.2013 23:23, Marcelo Tosatti wrote:
>> On Wed, May 22, 2013 at 03:22:55AM -0400, Vadim Rozenfeld wrote:
>>>
>>>
>>> ----- Original Message -----
>>> From: "Marcelo Tosatti" <mtosatti@redhat.com>
>>> To: "Vadim Rozenfeld" <vrozenfe@redhat.com>
>>> Cc: kvm@vger.kernel.org, gleb@redhat.com, pl@dlh.net
>>> Sent: Wednesday, May 22, 2013 10:50:46 AM
>>> Subject: Re: [RFC PATCH v2 2/2] add support for Hyper-V invariant TSC
>>>
>>> On Sun, May 19, 2013 at 05:06:37PM +1000, Vadim Rozenfeld wrote:
>>>> The following patch allows to activate a partition reference
>>>> time enlightenment that is based on the host platform's support
>>>> for an Invariant Time Stamp Counter (iTSC).
>>>> NOTE: This code will survive migration due to lack of VM stop/resume
>>>> handlers, when offset, scale and sequence should be
>>>> readjusted.
>>>>
>>>> ---
>>>>    arch/x86/kvm/x86.c | 6 +++++-
>>>>    1 file changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>>> index 9645dab..b423fe4 100644
>>>> --- a/arch/x86/kvm/x86.c
>>>> +++ b/arch/x86/kvm/x86.c
>>>> @@ -1838,7 +1838,6 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32 msr, u64 data)
>>>>    		u64 gfn;
>>>>    		unsigned long addr;
>>>>    		HV_REFERENCE_TSC_PAGE tsc_ref;
>>>> -		tsc_ref.TscSequence = 0;
>>>>    		if (!(data & HV_X64_MSR_TSC_REFERENCE_ENABLE)) {
>>>>    			kvm->arch.hv_tsc_page = data;
>>>>    			break;
>>>> @@ -1848,6 +1847,11 @@ static int set_msr_hyperv_pw(struct kvm_vcpu *vcpu, u32 msr, u64 data)
>>>>    				HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT);
>>>>    		if (kvm_is_error_hva(addr))
>>>>    			return 1;
>>>> +		tsc_ref.TscSequence =
>>>> +				boot_cpu_has(X86_FEATURE_CONSTANT_TSC) ? 1 : 0;
>>>
>>> 1) You want NONSTOP_TSC (see 40fb1715 commit) which matches INVARIANT TSC.
>>> [VR]
>>> Thank you for reviewing. Will fix it.
>>> 2) TscSequence should increase?
>>> "This field serves as a sequence number that is incremented whenever..."
>>> [VR]
>>> Yes, on every VM resume, including migration. After migration we also need
>>> to recalculate scale and adjust offset.
>>> 3) 0xFFFFFFFF is the value for invalid source of reference time?
>>> [VR] Yes, on boot-up. In this case guest will go with PMTimer (not sure about HPET
>>> but I can check). But if we set sequence to 0xFFFFFFFF after migration - it's probably will not work.
>>
>> "Reference TSC during Save and Restore and Migration
>>
>> To address migration scenarios to physical platforms that do not support
>> iTSC, the TscSequence field is used. In the event that a guest partition
>> is  migrated from an iTSC capable host to a non-iTSC capable host, the
>> hypervisor sets TscSequence to the special value of 0xFFFFFFFF, which
>> directs the guest operating system to fall back to a different clock
>> source (for example, the virtual PM timer)."
>>
>> Why it would not/does not work after migration?
>>
>>
>
> what exactly do we heed the reference TSC for? the reference counter alone works great and it seems
> that there is a lot of trouble and crash possibilities involved with the referece tsc.
>
> [VR]
> Because it is incredibly light and fast.
> The simple test which calls QueryPerformanceCounter in a
> loop 10 millions times gives we the following results:
> PMTimer     32269 ms
> HPET        38466 ms
> Ref Count   6499 ms
> iTSC        1169 ms

is the ref_count with local_irq_disable or preempt_disable?
[VR]
local_irq_disable

Peter


  parent reply	other threads:[~2013-05-23 12:54 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-19  7:06 [RFC PATCH v2 0/2] Hyper-V timers Vadim Rozenfeld
2013-05-19  7:06 ` [RFC PATCH v2 1/2] add support for Hyper-V reference time counter Vadim Rozenfeld
2013-05-19 13:47   ` Gleb Natapov
2013-05-19 14:37   ` Paolo Bonzini
2013-05-22  0:46   ` Marcelo Tosatti
2013-05-22  3:28     ` Gleb Natapov
2013-05-22  3:32       ` Marcelo Tosatti
2013-05-22  3:38         ` Gleb Natapov
2013-05-22 14:31           ` Marcelo Tosatti
2013-05-22  7:32     ` Vadim Rozenfeld
2013-05-22 21:55       ` Paolo Bonzini
2013-05-23  6:17         ` Peter Lieven
2013-05-23  9:54           ` Paolo Bonzini
2013-05-23 10:45             ` Peter Lieven
2013-05-23 12:25           ` Vadim Rozenfeld
2013-05-23 13:18             ` Paolo Bonzini
2013-05-23 13:20               ` Peter Lieven
2013-05-23 13:23                 ` Paolo Bonzini
2013-05-23 13:30                   ` Peter Lieven
2013-05-23 13:40                     ` Paolo Bonzini
2013-05-19  7:06 ` [RFC PATCH v2 2/2] add support for Hyper-V invariant TSC Vadim Rozenfeld
2013-05-22  0:50   ` Marcelo Tosatti
2013-05-22  7:22     ` Vadim Rozenfeld
2013-05-22 21:23       ` Marcelo Tosatti
2013-05-23  6:18         ` Peter Lieven
2013-05-23  9:13           ` Gleb Natapov
2013-05-23 13:35             ` Marcelo Tosatti
2013-05-23 15:14               ` Gleb Natapov
2013-05-24  9:57               ` Vadim Rozenfeld
2013-05-23 12:33           ` Vadim Rozenfeld
2013-05-23 12:44             ` Peter Lieven
2013-05-23 12:45               ` Gleb Natapov
2013-05-23 12:54               ` Vadim Rozenfeld [this message]
2013-05-23  9:12         ` Gleb Natapov
2013-05-23 13:53           ` Marcelo Tosatti
2013-05-23 15:31             ` Gleb Natapov
2013-05-24 10:11               ` Vadim Rozenfeld
2013-05-24 19:41                 ` Marcelo Tosatti
2013-05-27 12:33                   ` Vadim Rozenfeld
2013-05-23 12:21         ` Vadim Rozenfeld
2013-05-23 13:47           ` Marcelo Tosatti
2013-05-24 10:01             ` Vadim Rozenfeld
2013-05-23 16:44   ` Paolo Bonzini
2013-05-24 10:16     ` Vadim Rozenfeld

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=1350542924.6451148.1369313659560.JavaMail.root@redhat.com \
    --to=vrozenfe@redhat.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=pl@dlh.net \
    --cc=pl@dlhnet.de \
    /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