Re: [libvirt] [PATCH] qemu: hyperv: Add enlightenment support for TSC timekeeping

2014-02-05 Thread Vadim Rozenfeld
On Tue, 2014-02-04 at 16:04 +0100, Peter Krempa wrote:
 [adding Vadim as he implemented the qemu/kvm parts]
 
 On 01/22/14 11:35, Daniel P. Berrange wrote:
  On Tue, Jan 21, 2014 at 06:54:34PM +0100, Peter Krempa wrote:
  The hyperv enlightenment features allow to ease guests timekeeping by
  allowing to store offset from the TSC as a reference. Add the support
  for enabling this flag in qemu.
  
  I'm not sure I entirely understand what this is doing with TSC, but
  we do have a generic  timer element for controlling various attributes
  of platform timers. I can't help thinking it'd be better to keep this
  TSC related setting there instead
 
 This functionality provides hypercalls defined by the Microsoft's
 enlightenment standards. These provide calibration data and actual
 values that can be used by the guest to calculate time. [1]
 
 The actual implementation uses data provided by the kvmclock code:
 
 + case HV_X64_MSR_TIME_REF_COUNT: {
 + data =
 +  div_u64(get_kernel_ns() + kvm-arch.kvmclock_offset, 100);
 + break;
 + }
 
 along with a few values that will allow the guest to use the data.
 
 Technically this is a new timer for VM's running windows and as with
 kvmclock, cpu features are used to show the availability of this feature
 to the guest.
 
 There is yet another enlightenment option for windows guests that run
 on platforms that support the invariant TSC (iTSC). This option will add
 hypercall to retrieve calibration data so that the host processors iTSC
 will be used as the timing source eliminating the need to read the timer
 value via a hypercall.

Technically, it is not a hypercall, just a normal call RDTSC, but then
kernel normalizes the returned value to 10MHz and adds offset. Kernel
(KVM) shares scale and offset date with a guest through a dedicated page
allocated by guest. We have pretty good working prototype at the moment,
but this part has not been committed to upstream yet.

Best regards,
Vadim.

 
 I agree on your idea of moving this option into the timer section. How
 about naming it timer name=hv-rtc ?
 
  
  Daniel
  
 
 Peter
 
 [1]:
 http://msdn.microsoft.com/en-us/library/windows/hardware/ff542637(v=vs.85).aspx
 


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] qemu: hyperv: Add enlightenment support for TSC timekeeping

2014-02-04 Thread Peter Krempa
[adding Vadim as he implemented the qemu/kvm parts]

On 01/22/14 11:35, Daniel P. Berrange wrote:
 On Tue, Jan 21, 2014 at 06:54:34PM +0100, Peter Krempa wrote:
 The hyperv enlightenment features allow to ease guests timekeeping by
 allowing to store offset from the TSC as a reference. Add the support
 for enabling this flag in qemu.
 
 I'm not sure I entirely understand what this is doing with TSC, but
 we do have a generic  timer element for controlling various attributes
 of platform timers. I can't help thinking it'd be better to keep this
 TSC related setting there instead

This functionality provides hypercalls defined by the Microsoft's
enlightenment standards. These provide calibration data and actual
values that can be used by the guest to calculate time. [1]

The actual implementation uses data provided by the kvmclock code:

+   case HV_X64_MSR_TIME_REF_COUNT: {
+   data =
+div_u64(get_kernel_ns() + kvm-arch.kvmclock_offset, 100);
+   break;
+   }

along with a few values that will allow the guest to use the data.

Technically this is a new timer for VM's running windows and as with
kvmclock, cpu features are used to show the availability of this feature
to the guest.

There is yet another enlightenment option for windows guests that run
on platforms that support the invariant TSC (iTSC). This option will add
hypercall to retrieve calibration data so that the host processors iTSC
will be used as the timing source eliminating the need to read the timer
value via a hypercall.

I agree on your idea of moving this option into the timer section. How
about naming it timer name=hv-rtc ?

 
 Daniel
 

Peter

[1]:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542637(v=vs.85).aspx



signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] qemu: hyperv: Add enlightenment support for TSC timekeeping

2014-02-04 Thread Daniel P. Berrange
On Tue, Feb 04, 2014 at 04:04:06PM +0100, Peter Krempa wrote:
 [adding Vadim as he implemented the qemu/kvm parts]
 
 On 01/22/14 11:35, Daniel P. Berrange wrote:
  On Tue, Jan 21, 2014 at 06:54:34PM +0100, Peter Krempa wrote:
  The hyperv enlightenment features allow to ease guests timekeeping by
  allowing to store offset from the TSC as a reference. Add the support
  for enabling this flag in qemu.
  
  I'm not sure I entirely understand what this is doing with TSC, but
  we do have a generic  timer element for controlling various attributes
  of platform timers. I can't help thinking it'd be better to keep this
  TSC related setting there instead
 
 This functionality provides hypercalls defined by the Microsoft's
 enlightenment standards. These provide calibration data and actual
 values that can be used by the guest to calculate time. [1]
 
 The actual implementation uses data provided by the kvmclock code:
 
 + case HV_X64_MSR_TIME_REF_COUNT: {
 + data =
 +  div_u64(get_kernel_ns() + kvm-arch.kvmclock_offset, 100);
 + break;
 + }
 
 along with a few values that will allow the guest to use the data.
 
 Technically this is a new timer for VM's running windows and as with
 kvmclock, cpu features are used to show the availability of this feature
 to the guest.
 
 There is yet another enlightenment option for windows guests that run
 on platforms that support the invariant TSC (iTSC). This option will add
 hypercall to retrieve calibration data so that the host processors iTSC
 will be used as the timing source eliminating the need to read the timer
 value via a hypercall.
 
 I agree on your idea of moving this option into the timer section. How
 about naming it timer name=hv-rtc ?

Sounds reasonable, or  hyperv-rtc  since 'hv' can be misinterpreted to
just mean 'hypervisor'


Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] qemu: hyperv: Add enlightenment support for TSC timekeeping

2014-01-22 Thread Daniel P. Berrange
On Tue, Jan 21, 2014 at 06:54:34PM +0100, Peter Krempa wrote:
 The hyperv enlightenment features allow to ease guests timekeeping by
 allowing to store offset from the TSC as a reference. Add the support
 for enabling this flag in qemu.

I'm not sure I entirely understand what this is doing with TSC, but
we do have a generic  timer element for controlling various attributes
of platform timers. I can't help thinking it'd be better to keep this
TSC related setting there instead

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH] qemu: hyperv: Add enlightenment support for TSC timekeeping

2014-01-21 Thread Eric Blake
On 01/21/2014 10:54 AM, Peter Krempa wrote:
 The hyperv enlightenment features allow to ease guests timekeeping by
 allowing to store offset from the TSC as a reference. Add the support
 for enabling this flag in qemu.
 ---
 
 Notes:
 This feature is still under development in qemu. I will wait until it's 
 finished before pushing this:
 
 http://lists.nongnu.org/archive/html/qemu-devel/2014-01/msg02569.html

Looks okay code-wise, but I agree with holding off in libvirt.git until
after the qemu.git commit id is known.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list