xen/pcifront: Use monotonic clock

xen/pcifront: Use monotonic clock

[Abhilash Jindal]

[-- Attachment #1.1: Type: text/plain, Size: 1603 bytes --]

Wall time obtained from do_gettimeofday is susceptible to sudden jumps due
to user setting the time or due to NTP.

Monotonic time is constantly increasing time better suited for comparing two
timestamps.
---
 drivers/pci/xen-pcifront.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index f7197a7..5ef3eb7 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -114,7 +114,7 @@ static int do_pci_op(struct pcifront_device *pdev,
struct xen_pci_op *op)
  evtchn_port_t port = pdev->evtchn;
  unsigned irq = pdev->irq;
  s64 ns, ns_timeout;
- struct timeval tv;
+ struct timespec tv;

  spin_lock_irqsave(&pdev->sh_info_lock, irq_flags);

@@ -131,8 +131,8 @@ static int do_pci_op(struct pcifront_device *pdev,
struct xen_pci_op *op)
  * (in the latter case we end up continually re-executing poll() with a
  * timeout in the past). 1s difference gives plenty of slack for error.
  */
- do_gettimeofday(&tv);
- ns_timeout = timeval_to_ns(&tv) + 2 * (s64)NSEC_PER_SEC;
+ ktime_get_ts(&tv);
+ ns_timeout = timespec_to_ns(&tv) + 2 * (s64)NSEC_PER_SEC;

  xen_clear_irq_pending(irq);

@@ -140,8 +140,8 @@ static int do_pci_op(struct pcifront_device *pdev,
struct xen_pci_op *op)
  (unsigned long *)&pdev->sh_info->flags)) {
  xen_poll_irq_timeout(irq, jiffies + 3*HZ);
  xen_clear_irq_pending(irq);
- do_gettimeofday(&tv);
- ns = timeval_to_ns(&tv);
+ ktime_get_ts(&tv);
+ ns = timespec_to_ns(&tv);
  if (ns > ns_timeout) {
  dev_err(&pdev->xdev->dev,
  "pciback not responding!!!\n");
-- 
1.7.9.5

[-- Attachment #1.2: Type: text/html, Size: 3664 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xen/pcifront: Use monotonic clock

[Boris Ostrovsky]

On 08/08/2015 09:36 PM, Abhilash Jindal wrote:
> Wall time obtained from do_gettimeofday is susceptible to sudden jumps 
> due to user setting the time or due to NTP.
>
> Monotonic time is constantly increasing time better suited for 
> comparing two
> timestamps.

See commit e1d5bbcdc7ca08d8731f5d780f0de342a768d96a (you probably will 
need to update your tree)

-boris

> ---
>  drivers/pci/xen-pcifront.c |   10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
> index f7197a7..5ef3eb7 100644
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -114,7 +114,7 @@ static int do_pci_op(struct pcifront_device *pdev, 
> struct xen_pci_op *op)
> evtchn_port_t port = pdev->evtchn;
> unsigned irq = pdev->irq;
> s64 ns, ns_timeout;
> -struct timeval tv;
> +struct timespec tv;
> spin_lock_irqsave(&pdev->sh_info_lock, irq_flags);
> @@ -131,8 +131,8 @@ static int do_pci_op(struct pcifront_device *pdev, 
> struct xen_pci_op *op)
> * (in the latter case we end up continually re-executing poll() with a
> * timeout in the past). 1s difference gives plenty of slack for error.
> */
> -do_gettimeofday(&tv);
> -ns_timeout = timeval_to_ns(&tv) + 2 * (s64)NSEC_PER_SEC;
> +ktime_get_ts(&tv);
> +ns_timeout = timespec_to_ns(&tv) + 2 * (s64)NSEC_PER_SEC;
> xen_clear_irq_pending(irq);
> @@ -140,8 +140,8 @@ static int do_pci_op(struct pcifront_device *pdev, 
> struct xen_pci_op *op)
> (unsigned long *)&pdev->sh_info->flags)) {
> xen_poll_irq_timeout(irq, jiffies + 3*HZ);
> xen_clear_irq_pending(irq);
> -do_gettimeofday(&tv);
> -ns = timeval_to_ns(&tv);
> +ktime_get_ts(&tv);
> +ns = timespec_to_ns(&tv);
> if (ns > ns_timeout) {
> dev_err(&pdev->xdev->dev,
> "pciback not responding!!!\n");
> -- 
> 1.7.9.5
>

Re: xen/pcifront: Use monotonic clock

[Abhilash Jindal]

[-- Attachment #1.1: Type: text/plain, Size: 1978 bytes --]

Oops. Thank you.

On Sat, Aug 8, 2015 at 10:16 PM, Boris Ostrovsky <boris.ostrovsky@oracle.com
> wrote:

> On 08/08/2015 09:36 PM, Abhilash Jindal wrote:
>
>> Wall time obtained from do_gettimeofday is susceptible to sudden jumps
>> due to user setting the time or due to NTP.
>>
>> Monotonic time is constantly increasing time better suited for comparing
>> two
>> timestamps.
>>
>
> See commit e1d5bbcdc7ca08d8731f5d780f0de342a768d96a (you probably will
> need to update your tree)
>
> -boris
>
> ---
>>  drivers/pci/xen-pcifront.c |   10 +++++-----
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
>> index f7197a7..5ef3eb7 100644
>> --- a/drivers/pci/xen-pcifront.c
>> +++ b/drivers/pci/xen-pcifront.c
>> @@ -114,7 +114,7 @@ static int do_pci_op(struct pcifront_device *pdev,
>> struct xen_pci_op *op)
>> evtchn_port_t port = pdev->evtchn;
>> unsigned irq = pdev->irq;
>> s64 ns, ns_timeout;
>> -struct timeval tv;
>> +struct timespec tv;
>> spin_lock_irqsave(&pdev->sh_info_lock, irq_flags);
>> @@ -131,8 +131,8 @@ static int do_pci_op(struct pcifront_device *pdev,
>> struct xen_pci_op *op)
>> * (in the latter case we end up continually re-executing poll() with a
>> * timeout in the past). 1s difference gives plenty of slack for error.
>> */
>> -do_gettimeofday(&tv);
>> -ns_timeout = timeval_to_ns(&tv) + 2 * (s64)NSEC_PER_SEC;
>> +ktime_get_ts(&tv);
>> +ns_timeout = timespec_to_ns(&tv) + 2 * (s64)NSEC_PER_SEC;
>> xen_clear_irq_pending(irq);
>> @@ -140,8 +140,8 @@ static int do_pci_op(struct pcifront_device *pdev,
>> struct xen_pci_op *op)
>> (unsigned long *)&pdev->sh_info->flags)) {
>> xen_poll_irq_timeout(irq, jiffies + 3*HZ);
>> xen_clear_irq_pending(irq);
>> -do_gettimeofday(&tv);
>> -ns = timeval_to_ns(&tv);
>> +ktime_get_ts(&tv);
>> +ns = timespec_to_ns(&tv);
>> if (ns > ns_timeout) {
>> dev_err(&pdev->xdev->dev,
>> "pciback not responding!!!\n");
>> --
>> 1.7.9.5
>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 2797 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel