qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Bug 1860053] [NEW] Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le
@ 2020-01-16 23:32 Patrick Meiring
  2020-01-17  6:46 ` [Bug 1860053] " Philippe Mathieu-Daudé
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: Patrick Meiring @ 2020-01-16 23:32 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

Occurs on QEMU v4.2.0 run on docker (via the qemu-user-static:v4.2.0-2
image) on an AMD64 Ubuntu 18.04.3 LTS machine provided by travis-ci.org.

>From golang's https://github.com/golang/go/issues/36592:

It was discovered that golang's time.NewTicker() and time.Sleep()
malfunction when a compiled application was run via QEMU's ppc64le
emulator in user mode.

The methods did not malfunction on actual PowerPC hardware or when the
same golang application was compiled for golang's arm, arm64 or 386
targets and was run via user mode QEMU on the same system.

Curiously, the methods also worked when the program was compiled under
go 1.11, but do malfunction in go 1.12 and 1.13.

It was identified the change in behaviour was most likely attributable to golang switching to using vSDO for calling clock_gettime() on PowerPC 64 architectures in 1.12. I.E:
https://github.com/golang/go/commit/dbd8af74723d2c98cbdcc70f7e2801f69b57ac5b

We therefore suspect there may be a bug in QEMU's user-mode emulation of
ppc64le as relates to vDSO calls to clock_gettime().

The nature of the malfunction of time.NewTicker() and time.Sleep() is
such that sleeps or ticks with a granularity of less than one second do
not appear to be possible (they all revert to 1 second sleeps/ticks).
Could it be that the nanoseconds field of clock_gettime() is getting
lost in the vDSO version but not in the syscall? Or some other issue
calling these methods via vDSO?

Thanks in advance.

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1860053

Title:
  Possible lack of precision when calling clock_gettime via vDSO on user
  mode ppc64le

Status in QEMU:
  New

Bug description:
  Occurs on QEMU v4.2.0 run on docker (via the qemu-user-static:v4.2.0-2
  image) on an AMD64 Ubuntu 18.04.3 LTS machine provided by travis-
  ci.org.

  From golang's https://github.com/golang/go/issues/36592:

  It was discovered that golang's time.NewTicker() and time.Sleep()
  malfunction when a compiled application was run via QEMU's ppc64le
  emulator in user mode.

  The methods did not malfunction on actual PowerPC hardware or when the
  same golang application was compiled for golang's arm, arm64 or 386
  targets and was run via user mode QEMU on the same system.

  Curiously, the methods also worked when the program was compiled under
  go 1.11, but do malfunction in go 1.12 and 1.13.

  It was identified the change in behaviour was most likely attributable to golang switching to using vSDO for calling clock_gettime() on PowerPC 64 architectures in 1.12. I.E:
  https://github.com/golang/go/commit/dbd8af74723d2c98cbdcc70f7e2801f69b57ac5b

  We therefore suspect there may be a bug in QEMU's user-mode emulation
  of ppc64le as relates to vDSO calls to clock_gettime().

  The nature of the malfunction of time.NewTicker() and time.Sleep() is
  such that sleeps or ticks with a granularity of less than one second
  do not appear to be possible (they all revert to 1 second
  sleeps/ticks). Could it be that the nanoseconds field of
  clock_gettime() is getting lost in the vDSO version but not in the
  syscall? Or some other issue calling these methods via vDSO?

  Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1860053/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1860053] Re: Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le
  2020-01-16 23:32 [Bug 1860053] [NEW] Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le Patrick Meiring
@ 2020-01-17  6:46 ` Philippe Mathieu-Daudé
  2020-01-17 18:19 ` Richard Henderson
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-01-17  6:46 UTC (permalink / raw)
  To: qemu-devel

** Tags added: linux-user ppc

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1860053

Title:
  Possible lack of precision when calling clock_gettime via vDSO on user
  mode ppc64le

Status in QEMU:
  New

Bug description:
  Occurs on QEMU v4.2.0 run on docker (via the qemu-user-static:v4.2.0-2
  image) on an AMD64 Ubuntu 18.04.3 LTS machine provided by travis-
  ci.org.

  From golang's https://github.com/golang/go/issues/36592:

  It was discovered that golang's time.NewTicker() and time.Sleep()
  malfunction when a compiled application was run via QEMU's ppc64le
  emulator in user mode.

  The methods did not malfunction on actual PowerPC hardware or when the
  same golang application was compiled for golang's arm, arm64 or 386
  targets and was run via user mode QEMU on the same system.

  Curiously, the methods also worked when the program was compiled under
  go 1.11, but do malfunction in go 1.12 and 1.13.

  It was identified the change in behaviour was most likely attributable to golang switching to using vSDO for calling clock_gettime() on PowerPC 64 architectures in 1.12. I.E:
  https://github.com/golang/go/commit/dbd8af74723d2c98cbdcc70f7e2801f69b57ac5b

  We therefore suspect there may be a bug in QEMU's user-mode emulation
  of ppc64le as relates to vDSO calls to clock_gettime().

  The nature of the malfunction of time.NewTicker() and time.Sleep() is
  such that sleeps or ticks with a granularity of less than one second
  do not appear to be possible (they all revert to 1 second
  sleeps/ticks). Could it be that the nanoseconds field of
  clock_gettime() is getting lost in the vDSO version but not in the
  syscall? Or some other issue calling these methods via vDSO?

  Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1860053/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1860053] Re: Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le
  2020-01-16 23:32 [Bug 1860053] [NEW] Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le Patrick Meiring
  2020-01-17  6:46 ` [Bug 1860053] " Philippe Mathieu-Daudé
@ 2020-01-17 18:19 ` Richard Henderson
  2020-01-17 21:51 ` Fabiano Rosas
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Richard Henderson @ 2020-01-17 18:19 UTC (permalink / raw)
  To: qemu-devel

QEMU does not implement any vDSO, so this cannot be the explanation.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1860053

Title:
  Possible lack of precision when calling clock_gettime via vDSO on user
  mode ppc64le

Status in QEMU:
  New

Bug description:
  Occurs on QEMU v4.2.0 run on docker (via the qemu-user-static:v4.2.0-2
  image) on an AMD64 Ubuntu 18.04.3 LTS machine provided by travis-
  ci.org.

  From golang's https://github.com/golang/go/issues/36592:

  It was discovered that golang's time.NewTicker() and time.Sleep()
  malfunction when a compiled application was run via QEMU's ppc64le
  emulator in user mode.

  The methods did not malfunction on actual PowerPC hardware or when the
  same golang application was compiled for golang's arm, arm64 or 386
  targets and was run via user mode QEMU on the same system.

  Curiously, the methods also worked when the program was compiled under
  go 1.11, but do malfunction in go 1.12 and 1.13.

  It was identified the change in behaviour was most likely attributable to golang switching to using vSDO for calling clock_gettime() on PowerPC 64 architectures in 1.12. I.E:
  https://github.com/golang/go/commit/dbd8af74723d2c98cbdcc70f7e2801f69b57ac5b

  We therefore suspect there may be a bug in QEMU's user-mode emulation
  of ppc64le as relates to vDSO calls to clock_gettime().

  The nature of the malfunction of time.NewTicker() and time.Sleep() is
  such that sleeps or ticks with a granularity of less than one second
  do not appear to be possible (they all revert to 1 second
  sleeps/ticks). Could it be that the nanoseconds field of
  clock_gettime() is getting lost in the vDSO version but not in the
  syscall? Or some other issue calling these methods via vDSO?

  Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1860053/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1860053] Re: Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le
  2020-01-16 23:32 [Bug 1860053] [NEW] Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le Patrick Meiring
  2020-01-17  6:46 ` [Bug 1860053] " Philippe Mathieu-Daudé
  2020-01-17 18:19 ` Richard Henderson
@ 2020-01-17 21:51 ` Fabiano Rosas
  2020-01-19 22:28 ` Patrick Meiring
  2020-01-19 22:38 ` Patrick Meiring
  4 siblings, 0 replies; 6+ messages in thread
From: Fabiano Rosas @ 2020-01-17 21:51 UTC (permalink / raw)
  To: qemu-devel

Since there is no vdso, the Go code goes into the syscall fallback:

MOVD	runtime·vdsoClockgettimeSym(SB), R12	// Check for VDSO availability
CMP	R12, R0
BEQ	fallback
(...)
fallback:
	ADD	$32, R1, R4
	SYSCALL $SYS_clock_gettime
	MOVD	32(R1), R3
	MOVD	48(R1), R5
	JMP	finish

But upon inspection, it seems the offset while loading R5 is not
correct:

in QEMU's clock_gettime implementation:	
(gdb) p/x *host_ts
$8 = {tv_sec = 0x9225f, tv_nsec = 0x375f74ee}

in the Go runtime:
(gdb) p/x *($r1 + 48)
$6 = 0x388c8
(gdb) p/x *($r1 + 40)
$7 = 0x375f74ee

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1860053

Title:
  Possible lack of precision when calling clock_gettime via vDSO on user
  mode ppc64le

Status in QEMU:
  New

Bug description:
  Occurs on QEMU v4.2.0 run on docker (via the qemu-user-static:v4.2.0-2
  image) on an AMD64 Ubuntu 18.04.3 LTS machine provided by travis-
  ci.org.

  From golang's https://github.com/golang/go/issues/36592:

  It was discovered that golang's time.NewTicker() and time.Sleep()
  malfunction when a compiled application was run via QEMU's ppc64le
  emulator in user mode.

  The methods did not malfunction on actual PowerPC hardware or when the
  same golang application was compiled for golang's arm, arm64 or 386
  targets and was run via user mode QEMU on the same system.

  Curiously, the methods also worked when the program was compiled under
  go 1.11, but do malfunction in go 1.12 and 1.13.

  It was identified the change in behaviour was most likely attributable to golang switching to using vSDO for calling clock_gettime() on PowerPC 64 architectures in 1.12. I.E:
  https://github.com/golang/go/commit/dbd8af74723d2c98cbdcc70f7e2801f69b57ac5b

  We therefore suspect there may be a bug in QEMU's user-mode emulation
  of ppc64le as relates to vDSO calls to clock_gettime().

  The nature of the malfunction of time.NewTicker() and time.Sleep() is
  such that sleeps or ticks with a granularity of less than one second
  do not appear to be possible (they all revert to 1 second
  sleeps/ticks). Could it be that the nanoseconds field of
  clock_gettime() is getting lost in the vDSO version but not in the
  syscall? Or some other issue calling these methods via vDSO?

  Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1860053/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1860053] Re: Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le
  2020-01-16 23:32 [Bug 1860053] [NEW] Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le Patrick Meiring
                   ` (2 preceding siblings ...)
  2020-01-17 21:51 ` Fabiano Rosas
@ 2020-01-19 22:28 ` Patrick Meiring
  2020-01-19 22:38 ` Patrick Meiring
  4 siblings, 0 replies; 6+ messages in thread
From: Patrick Meiring @ 2020-01-19 22:28 UTC (permalink / raw)
  To: qemu-devel

** Changed in: qemu
       Status: New => Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1860053

Title:
  Possible lack of precision when calling clock_gettime via vDSO on user
  mode ppc64le

Status in QEMU:
  Invalid

Bug description:
  Occurs on QEMU v4.2.0 run on docker (via the qemu-user-static:v4.2.0-2
  image) on an AMD64 Ubuntu 18.04.3 LTS machine provided by travis-
  ci.org.

  From golang's https://github.com/golang/go/issues/36592:

  It was discovered that golang's time.NewTicker() and time.Sleep()
  malfunction when a compiled application was run via QEMU's ppc64le
  emulator in user mode.

  The methods did not malfunction on actual PowerPC hardware or when the
  same golang application was compiled for golang's arm, arm64 or 386
  targets and was run via user mode QEMU on the same system.

  Curiously, the methods also worked when the program was compiled under
  go 1.11, but do malfunction in go 1.12 and 1.13.

  It was identified the change in behaviour was most likely attributable to golang switching to using vSDO for calling clock_gettime() on PowerPC 64 architectures in 1.12. I.E:
  https://github.com/golang/go/commit/dbd8af74723d2c98cbdcc70f7e2801f69b57ac5b

  We therefore suspect there may be a bug in QEMU's user-mode emulation
  of ppc64le as relates to vDSO calls to clock_gettime().

  The nature of the malfunction of time.NewTicker() and time.Sleep() is
  such that sleeps or ticks with a granularity of less than one second
  do not appear to be possible (they all revert to 1 second
  sleeps/ticks). Could it be that the nanoseconds field of
  clock_gettime() is getting lost in the vDSO version but not in the
  syscall? Or some other issue calling these methods via vDSO?

  Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1860053/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug 1860053] Re: Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le
  2020-01-16 23:32 [Bug 1860053] [NEW] Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le Patrick Meiring
                   ` (3 preceding siblings ...)
  2020-01-19 22:28 ` Patrick Meiring
@ 2020-01-19 22:38 ` Patrick Meiring
  4 siblings, 0 replies; 6+ messages in thread
From: Patrick Meiring @ 2020-01-19 22:38 UTC (permalink / raw)
  To: qemu-devel

Thank you Fabiano for investigating.

It seems the golang side agrees with your analysis:
https://github.com/golang/go/issues/36592

I have marked this bug invalid for now. Thank you for your help.

Regards,
Patrick

** Bug watch added: github.com/golang/go/issues #36592
   https://github.com/golang/go/issues/36592

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1860053

Title:
  Possible lack of precision when calling clock_gettime via vDSO on user
  mode ppc64le

Status in QEMU:
  Invalid

Bug description:
  Occurs on QEMU v4.2.0 run on docker (via the qemu-user-static:v4.2.0-2
  image) on an AMD64 Ubuntu 18.04.3 LTS machine provided by travis-
  ci.org.

  From golang's https://github.com/golang/go/issues/36592:

  It was discovered that golang's time.NewTicker() and time.Sleep()
  malfunction when a compiled application was run via QEMU's ppc64le
  emulator in user mode.

  The methods did not malfunction on actual PowerPC hardware or when the
  same golang application was compiled for golang's arm, arm64 or 386
  targets and was run via user mode QEMU on the same system.

  Curiously, the methods also worked when the program was compiled under
  go 1.11, but do malfunction in go 1.12 and 1.13.

  It was identified the change in behaviour was most likely attributable to golang switching to using vSDO for calling clock_gettime() on PowerPC 64 architectures in 1.12. I.E:
  https://github.com/golang/go/commit/dbd8af74723d2c98cbdcc70f7e2801f69b57ac5b

  We therefore suspect there may be a bug in QEMU's user-mode emulation
  of ppc64le as relates to vDSO calls to clock_gettime().

  The nature of the malfunction of time.NewTicker() and time.Sleep() is
  such that sleeps or ticks with a granularity of less than one second
  do not appear to be possible (they all revert to 1 second
  sleeps/ticks). Could it be that the nanoseconds field of
  clock_gettime() is getting lost in the vDSO version but not in the
  syscall? Or some other issue calling these methods via vDSO?

  Thanks in advance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1860053/+subscriptions


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-01-19 22:46 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-16 23:32 [Bug 1860053] [NEW] Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le Patrick Meiring
2020-01-17  6:46 ` [Bug 1860053] " Philippe Mathieu-Daudé
2020-01-17 18:19 ` Richard Henderson
2020-01-17 21:51 ` Fabiano Rosas
2020-01-19 22:28 ` Patrick Meiring
2020-01-19 22:38 ` Patrick Meiring

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).