lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 02 Feb 2021 14:15:15 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Jianyong Wu <jianyong.wu@....com>
Cc:     netdev@...r.kernel.org, yangbo.lu@....com, john.stultz@...aro.org,
        tglx@...utronix.de, pbonzini@...hat.com, richardcochran@...il.com,
        Mark.Rutland@....com, will@...nel.org, suzuki.poulose@....com,
        Andre.Przywara@....com, steven.price@....com,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        kvmarm@...ts.cs.columbia.edu, kvm@...r.kernel.org,
        Steve.Capper@....com, justin.he@....com, nd@....com
Subject: Re: [PATCH v16 0/9] Enable ptp_kvm for arm/arm64

On 2020-12-09 06:09, Jianyong Wu wrote:
> Currently, we offen use ntp (sync time with remote network clock)
> to sync time in VM. But the precision of ntp is subject to network 
> delay
> so it's difficult to sync time in a high precision.
> 
> kvm virtual ptp clock (ptp_kvm) offers another way to sync time in VM,
> as the remote clock locates in the host instead of remote network 
> clock.
> It targets to sync time between guest and host in virtualization
> environment and in this way, we can keep the time of all the VMs 
> running
> in the same host in sync. In general, the delay of communication 
> between
> host and guest is quiet small, so ptp_kvm can offer time sync precision
> up to in order of nanosecond. Please keep in mind that ptp_kvm just
> limits itself to be a channel which transmit the remote clock from
> host to guest and leaves the time sync jobs to an application, eg. 
> chrony,
> in usersapce in VM.
> 
> How ptp_kvm works:
> After ptp_kvm initialized, there will be a new device node under
> /dev called ptp%d. A guest userspace service, like chrony, can use this
> device to get host walltime, sometimes also counter cycle, which 
> depends
> on the service it calls. Then this guest userspace service can use 
> those
> data to do the time sync for guest.
> here is a rough sketch to show how kvm ptp clock works.
> 
> |----------------------------|              
> |--------------------------|
> |       guest userspace      |              |          host            
> |
> |ioctl -> /dev/ptp%d         |              |                          
> |
> |       ^   |                |              |                          
> |
> |----------------------------|              |                          
> |
> |       |   | guest kernel   |              |                          
> |
> |       |   V      (get host walltime/counter cycle)                   
> |
> |      ptp_kvm -> hypercall - - - - - - - - - - ->hypercall service    
> |
> |                         <- - - - - - - - - - - -                     
> |
> |----------------------------|              
> |--------------------------|
> 
> 1. time sync service in guest userspace call ptp device through 
> /dev/ptp%d.
> 2. ptp_kvm module in guest receives this request then invoke hypercall 
> to route
> into host kernel to request host walltime/counter cycle.
> 3. ptp_kvm hypercall service in host response to the request and send 
> data back.
> 4. ptp (not ptp_kvm) in guest copy the data to userspace.
> 
> This ptp_kvm implementation focuses itself to step 2 and 3 and step 2 
> works
> in guest comparing step 3 works in host kernel.

FWIW, and in order to speed up the review, I've posted a reworked
version[0] of this series with changes that address the comments
I had for on v16.

Thanks,

         M.

[0] https://lore.kernel.org/r/20210202141204.3134855-1-maz@kernel.org
-- 
Jazz is not dead. It just smells funny...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ