date:20200322

Re: [PATCH-for-5.0 v2 07/11] hw/gpio/aspeed_gpio: Remove dead assignment

2020-03-22 Thread Cédric Le Goater

On 3/21/20 3:41 PM, Philippe Mathieu-Daudé wrote:
> Fix warning reported by Clang static code analyzer:
> 
>   hw/gpio/aspeed_gpio.c:717:18: warning: Value stored to 'g_idx' during its 
> initialization is never read
>   int set_idx, g_idx = *group_idx;
>^   ~~
> 
> Reported-by: Clang Static Analyzer
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Cédric Le Goater 

> ---
> v2: Do not declare g_idx in for() (Zoltan)
> ---
>  hw/gpio/aspeed_gpio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
> index 41e11ea9b0..bd19db31f4 100644
> --- a/hw/gpio/aspeed_gpio.c
> +++ b/hw/gpio/aspeed_gpio.c
> @@ -714,7 +714,7 @@ static void aspeed_gpio_write(void *opaque, hwaddr 
> offset, uint64_t data,
>  static int get_set_idx(AspeedGPIOState *s, const char *group, int *group_idx)
>  {
>  AspeedGPIOClass *agc = ASPEED_GPIO_GET_CLASS(s);
> -int set_idx, g_idx = *group_idx;
> +int set_idx, g_idx;
>  
>  for (set_idx = 0; set_idx < agc->nr_gpio_sets; set_idx++) {
>  const GPIOSetProperties *set_props = &agc->props[set_idx];
>

Re: [PATCH] ppc/ppc405_boards: Remove unnecessary NULL check

2020-03-22 Thread David Gibson

On Fri, Mar 20, 2020 at 04:57:40PM +0100, Philippe Mathieu-Daudé wrote:
> This code is inside the "if (dinfo)" condition, so testing
> again here whether it is NULL is unnecessary.
> 
> Fixes: dd59bcae7 (Don't size flash memory to match backing image)
> Reported-by: Coverity (CID 1421917)
> Suggested-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 

Applied to ppc-for-5.1.

> ---
>  hw/ppc/ppc405_boards.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
> index e6bffb9e1a..6198ec1035 100644
> --- a/hw/ppc/ppc405_boards.c
> +++ b/hw/ppc/ppc405_boards.c
> @@ -191,7 +191,7 @@ static void ref405ep_init(MachineState *machine)
>  bios_size = 8 * MiB;
>  pflash_cfi02_register((uint32_t)(-bios_size),
>"ef405ep.bios", bios_size,
> -  dinfo ? blk_by_legacy_dinfo(dinfo) : NULL,
> +  blk_by_legacy_dinfo(dinfo),
>64 * KiB, 1,
>2, 0x0001, 0x22DA, 0x, 0x, 0x555, 
> 0x2AA,
>1);
> @@ -459,7 +459,7 @@ static void taihu_405ep_init(MachineState *machine)
>  bios_size = 2 * MiB;
>  pflash_cfi02_register(0xFFE0,
>"taihu_405ep.bios", bios_size,
> -  dinfo ? blk_by_legacy_dinfo(dinfo) : NULL,
> +  blk_by_legacy_dinfo(dinfo),
>64 * KiB, 1,
>4, 0x0001, 0x22DA, 0x, 0x, 0x555, 
> 0x2AA,
>1);
> @@ -494,7 +494,7 @@ static void taihu_405ep_init(MachineState *machine)
>  if (dinfo) {
>  bios_size = 32 * MiB;
>  pflash_cfi02_register(0xfc00, "taihu_405ep.flash", bios_size,
> -  dinfo ? blk_by_legacy_dinfo(dinfo) : NULL,
> +  blk_by_legacy_dinfo(dinfo),
>64 * KiB, 1,
>4, 0x0001, 0x22DA, 0x, 0x, 0x555, 
> 0x2AA,
>1);

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

[Bug 1861161] Re: qemu-arm-static stuck with 100% CPU when cross-compiling emacs

2020-03-22 Thread Philippe Vaucher

I tried several workarounds including removing `dir_index` from ext4
partitions and using a 32 bit qemu-user-static version, but it does not
work:

The process still gets stuck in a loop involving `getdents64`:


```
root@earth:~# file /usr/bin/qemu-arm-static
/usr/bin/qemu-arm-static: ELF 32-bit LSB executable, Intel 80386, version 1 
(GNU/Linux), statically linked, for GNU/Linux 3.2.0, 
BuildID[sha1]=ff1224d87ca5dece8d0b0f5735cfee7fae97ee58, stripped

root@earth:~# ps afx | grep qemu
21031 pts/0S+ 0:00  \_ grep --color=auto qemu
 1036 ?Ss 0:00 /usr/sbin/qemu-ga --daemonize -m virtio-serial -p 
/dev/virtio-ports/org.qemu.guest_agent.0
10584 ?Ssl0:00  |   |   \_ /usr/bin/qemu-arm-static 
/usr/bin/make install
28768 ?Sl 0:01  |   |   \_ /usr/bin/qemu-arm-static 
/usr/bin/make -C src VCSWITNESS=$(srcdir)/../.git/logs/HEAD all
16718 ?Sl 0:00  |   |   \_ /usr/bin/qemu-arm-static 
/usr/bin/make -C ../lisp compile-first EMACS=../src/bootstrap-emacs
16726 ?Rl48:24  |   |   \_ /usr/bin/qemu-arm-static 
../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval (setq 
load-prefer-newer t) -f batch-byte-compile emacs-lisp/macroexp.el
10696 ?Ssl0:00  |   \_ /usr/bin/qemu-aarch64-static 
/usr/bin/make install
10972 ?Sl 0:02  |   \_ /usr/bin/qemu-aarch64-static 
/usr/bin/make -C src VCSWITNESS=$(srcdir)/../.git/logs/HEAD all
20397 ?Sl 0:00  |   \_ /usr/bin/qemu-aarch64-static 
/usr/bin/make -C ../lisp compile-first EMACS=../src/bootstrap-emacs
20405 ?Rl24:09  |   \_ 
/usr/bin/qemu-aarch64-static ../src/bootstrap-emacs -batch --no-site-file 
--no-site-lisp --eval (setq load-prefer-newer t) -f batch-byte-compile 
emacs-lisp/macroexp.el

root@earth:~# strace -p 16726
clock_gettime(CLOCK_REALTIME, {tv_sec=1584794027, tv_nsec=921230669}) = 0
getdents64(5, /* 0 entries */, 2048)= 0
_llseek(5, 0, [0], SEEK_SET)= 0
getdents64(5, /* 5 entries */, 2048)= 144
tgkill(29984, 29987, SIGRT_2)   = -1 EAGAIN (Resource temporarily 
unavailable)
clock_gettime(CLOCK_REALTIME, {tv_sec=1584794027, tv_nsec=921642405}) = 0
getdents64(5, /* 0 entries */, 2048)= 0
_llseek(5, 0, [0], SEEK_SET)= 0
getdents64(5, /* 5 entries */, 2048)= 144
tgkill(29984, 29987, SIGRT_2)   = -1 EAGAIN (Resource temporarily 
unavailable)
clock_gettime(CLOCK_REALTIME, {tv_sec=1584794027, tv_nsec=922333065}) = 0
getdents64(5, /* 0 entries */, 2048)= 0
_llseek(5, 0, [0], SEEK_SET)= 0
getdents64(5, /* 5 entries */, 2048)= 144
tgkill(29984, 29987, SIGRT_2)   = -1 EAGAIN (Resource temporarily 
unavailable)
clock_gettime(CLOCK_REALTIME, ^C{tv_sec=1584794027, tv_nsec=923201432}) = 0
strace: Process 16726 detached
```

What is interesting is that the qemu-aarch64-static process also get
stuck, which if I understand the bug correctly should not happen. I'll
try stracing the process to figure out what happens.

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

Title:
  qemu-arm-static stuck with 100% CPU when cross-compiling emacs

Status in QEMU:
  New

Bug description:
  Hello,

  I'm trying to build multi-arch docker images for
  https://hub.docker.com/r/silex/emacs.

  Here is the machine I'm building on (hetzner cloud machine):

  root@ubuntu-4gb-fsn1-1:~# lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 18.04.3 LTS
  Release:18.04
  Codename:   bionic
  root@ubuntu-4gb-fsn1-1:~# uname -a
  Linux ubuntu-4gb-fsn1-1 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

  Whenever I try to build the following alpine Dockerfile
  https://gitlab.com/Silex777/docker-
  emacs/blob/master/26.3/alpine/3.9/dev/Dockerfile like this:

  $ sysctl kernel.randomize_va_space=0
  $ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
  $ docker build --pull -t test --platform arm .

  It builds fine until this:

  root@ubuntu-4gb-fsn1-1:~# ps -ef | grep qemu
  root 26473 26465 99 14:26 pts/001:59:58 /usr/bin/qemu-arm-static 
../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval (setq 
load-prefer-newer t) -f batch-byte-compile emacs-lisp/macroexp.el

  This is supposed to take a few seconds, but here it takes 100% CPU and
  never ends. When I strace the process I see a never ending loop like
  this:

  getdents64(5, /* 0 entries */, 2048)= 0
  lseek(5, 0, SEEK_SET)   = 0
  getdents64(5, /* 5 entries */, 2048)= 120
  tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily 
unavailable)
  getdents64(5, /* 0 entries */, 2048)= 0
  lseek(5, 0, SEEK_SET)   = 0
  getdents64(5, /* 5 entries

Re: In tree configure errors since 6116aea9

2020-03-22 Thread Laurent Vivier

Le 21/03/2020 à 19:31, BALATON Zoltan a écrit :
> On Sat, 21 Mar 2020, Laurent Vivier wrote:
>> Le 21/03/2020 à 18:29, BALATON Zoltan a écrit :
>>> Hello,
>>>
>>> Since 6116aea99, or actually 4d6a835d (linux-user: introduce parameters
>>> to generate syscall_nr.h) but only next commit starts to enable it I get
>>> these errors when running configure in source tree:
>>>
>>> grep: ./.gitlab-ci.d: Is a directory
>>> grep: ./scripts/qemu-guest-agent/fsfreeze-hook.d: Is a directory
>>>
>>> for each entry in that loop over arches. Could this be silenced?
>>
>> I didn't see that because I always do an out-of-tree build.
> 
> Isn't there a test for that or should there be one?
> 
>> Could you try this?
>>
>> --- a/configure
>> +++ b/configure
>> @@ -1911,6 +1911,7 @@ for arch in alpha hppa m68k xtensa sh4 microblaze
>> arm ppc s390x sparc sparc64 \
>>     rm -f "${source_path}/linux-user/${arch}/syscall_nr.h"
>>     # remove the dependency files
>>     find . -name "*.d" \
>> +   -type f \
>>    -exec grep -q
>> "${source_path}/linux-user/${arch}/syscall_nr.h" {} \; \
>>    -exec rm {} \;
>> done
> 
> This gets rid of the errors but seems to be much slower:
> 
> with 4d6a835d running my usual configure script:
> 
> real    0m5.968s
> user    0m4.642s
> sys    0m1.402s
> 
> with HEAD and above patch:
> 
> real    0m20.246s
> user    0m14.143s
> sys    0m6.152s
> 
> Given that configure is rerun when some files change if there's a way to
> get at least the previous speed back might be better if possible.
> 
> Regards,
> BALATON Zoltan

Could you try this:

--- a/configure
+++ b/configure
@@ -1910,9 +1910,9 @@ for arch in alpha hppa m68k xtensa sh4 microblaze
arm ppc s390x sparc sparc64 \
 # remove the file if it has been generated in the source directory
 rm -f "${source_path}/linux-user/${arch}/syscall_nr.h"
 # remove the dependency files
-find . -name "*.d" \
-   -exec grep -q
"${source_path}/linux-user/${arch}/syscall_nr.h" {} \; \
-   -exec rm {} \;
+test -d ${arch}-linux-user && find ${arch}-linux-user -type f -name
"*.d" \
+ -exec grep -q "${source_path}/linux-user/${arch}/syscall_nr.h"
{} \; \
+ -exec rm {} \;
 done

 if test -z "$python"

Thanks,
Laurent

Re: [PATCH] ppc/ppc405_boards: Remove unnecessary NULL check

2020-03-22 Thread Peter Maydell

On Sun, 22 Mar 2020 at 08:50, David Gibson  wrote:
>
> On Fri, Mar 20, 2020 at 04:57:40PM +0100, Philippe Mathieu-Daudé wrote:
> > This code is inside the "if (dinfo)" condition, so testing
> > again here whether it is NULL is unnecessary.
> >
> > Fixes: dd59bcae7 (Don't size flash memory to match backing image)
> > Reported-by: Coverity (CID 1421917)
> > Suggested-by: Peter Maydell 
> > Signed-off-by: Philippe Mathieu-Daudé 
>
> Applied to ppc-for-5.1.

This would be OK for 5.0 too at this stage.

thanks
-- PMM

Re: [PATCH 0/3] target/arm: Coverity tweaks

2020-03-22 Thread Philippe Mathieu-Daudé


On 3/20/20 5:06 PM, Richard Henderson wrote:

Only the first of these appears to be a real bug.
The other two are adjustments to help satisfy Coverity.


r~


Richard Henderson (3):
   target/arm: Rearrange disabled check for watchpoints
   target/arm: Assert immh != 0 in disas_simd_shift_imm
   target/arm: Move computation of index in handle_simd_dupe

  target/arm/helper.c| 11 ++-
  target/arm/translate-a64.c |  6 +-
  2 files changed, 11 insertions(+), 6 deletions(-)



Series:
Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v2 4/6] linux-user/flatload.c: Use "" for include of QEMU header target_flat.h

2020-03-22 Thread Philippe Mathieu-Daudé


On 3/19/20 8:33 PM, Peter Maydell wrote:

The target_flat.h file is a QEMU header, so we should include it using
quotes, not angle brackets.

Coverity otherwise is unable to find the header:

"../linux-user/flatload.c", line 40: error #1712: cannot open source file
   "target_flat.h"
   #include 
   ^

because the relevant directory is only on the -iquote path, not the -I path.

Signed-off-by: Peter Maydell 
---
I don't know why Coverity in particular has trouble here but
real compilers don't. Still, the "" is the right thing.
---
  linux-user/flatload.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linux-user/flatload.c b/linux-user/flatload.c
index 0122ab3afe6..66901f39cc5 100644
--- a/linux-user/flatload.c
+++ b/linux-user/flatload.c
@@ -37,7 +37,7 @@
  
  #include "qemu.h"

  #include "flat.h"
-#include 
+#include "target_flat.h"
  
  //#define DEBUG
  



Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v2 3/6] thread.h: Remove trailing semicolons from Coverity qemu_mutex_lock() etc

2020-03-22 Thread Philippe Mathieu-Daudé


On 3/19/20 8:33 PM, Peter Maydell wrote:

All the Coverity-specific definitions of qemu_mutex_lock() and friends
have a trailing semicolon. This works fine almost everywhere because
of QEMU's mandatory-braces coding style and because most callsites are
simple, but target/s390x/sigp.c has a use of qemu_mutex_trylock() as
an if() statement, which makes the ';' a syntax error:
"../target/s390x/sigp.c", line 461: warning #18: expected a ")"
   if (qemu_mutex_trylock(&qemu_sigp_mutex)) {
   ^

Remove the bogus semicolons from the macro definitions.

Signed-off-by: Peter Maydell 
---
  include/qemu/thread.h | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/qemu/thread.h b/include/qemu/thread.h
index 10262c63f58..d22848138ea 100644
--- a/include/qemu/thread.h
+++ b/include/qemu/thread.h
@@ -57,17 +57,17 @@ extern QemuCondTimedWaitFunc qemu_cond_timedwait_func;
   * hide them.
   */
  #define qemu_mutex_lock(m)  \
-qemu_mutex_lock_impl(m, __FILE__, __LINE__);
+qemu_mutex_lock_impl(m, __FILE__, __LINE__)
  #define qemu_mutex_trylock(m)   \
-qemu_mutex_trylock_impl(m, __FILE__, __LINE__);
+qemu_mutex_trylock_impl(m, __FILE__, __LINE__)
  #define qemu_rec_mutex_lock(m)  \
-qemu_rec_mutex_lock_impl(m, __FILE__, __LINE__);
+qemu_rec_mutex_lock_impl(m, __FILE__, __LINE__)
  #define qemu_rec_mutex_trylock(m)   \
-qemu_rec_mutex_trylock_impl(m, __FILE__, __LINE__);
+qemu_rec_mutex_trylock_impl(m, __FILE__, __LINE__)
  #define qemu_cond_wait(c, m)\
-qemu_cond_wait_impl(c, m, __FILE__, __LINE__);
+qemu_cond_wait_impl(c, m, __FILE__, __LINE__)
  #define qemu_cond_timedwait(c, m, ms)   \
-qemu_cond_timedwait_impl(c, m, ms, __FILE__, __LINE__);
+qemu_cond_timedwait_impl(c, m, ms, __FILE__, __LINE__)
  #else
  #define qemu_mutex_lock(m) ({   \
  QemuMutexLockFunc _f = atomic_read(&qemu_mutex_lock_func);  \



Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH v2 2/6] thread.h: Fix Coverity version of qemu_cond_timedwait()

2020-03-22 Thread Philippe Mathieu-Daudé


On 3/19/20 8:33 PM, Peter Maydell wrote:

For Coverity's benefit, we provide simpler versions of functions like
qemu_mutex_lock(), qemu_cond_wait() and qemu_cond_timedwait().  When
we added qemu_cond_timedwait() in commit 3dcc9c6ec4ea, a cut and
paste error meant that the Coverity version of qemu_cond_timedwait()
was using the wrong _impl function, which makes the Coverity parser
complain:

"/qemu/include/qemu/thread.h", line 159: warning #140: too many arguments in
   function call
   return qemu_cond_timedwait(cond, mutex, ms);
  ^

"/qemu/include/qemu/thread.h", line 159: warning #120: return value type does
   not match the function type
   return qemu_cond_timedwait(cond, mutex, ms);
  ^

"/qemu/include/qemu/thread.h", line 156: warning #1563: function
   "qemu_cond_timedwait" not emitted, consider modeling it or review
   parse diagnostics to improve fidelity
   static inline bool (qemu_cond_timedwait)(QemuCond *cond, QemuMutex *mutex,
   ^

These aren't fatal, but reduce the scope of the analysis. Fix the error.

Signed-off-by: Peter Maydell 
---
  include/qemu/thread.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/qemu/thread.h b/include/qemu/thread.h
index 047db0307e7..10262c63f58 100644
--- a/include/qemu/thread.h
+++ b/include/qemu/thread.h
@@ -67,7 +67,7 @@ extern QemuCondTimedWaitFunc qemu_cond_timedwait_func;
  #define qemu_cond_wait(c, m)\
  qemu_cond_wait_impl(c, m, __FILE__, __LINE__);
  #define qemu_cond_timedwait(c, m, ms)   \
-qemu_cond_wait_impl(c, m, ms, __FILE__, __LINE__);
+qemu_cond_timedwait_impl(c, m, ms, __FILE__, __LINE__);
  #else
  #define qemu_mutex_lock(m) ({   \
  QemuMutexLockFunc _f = atomic_read(&qemu_mutex_lock_func);  \



Reviewed-by: Philippe Mathieu-Daudé

Re: [PATCH-for-5.0 v2 2/4] tests/test-util-sockets: Skip test on non-x86 Travis containers

2020-03-22 Thread Philippe Mathieu-Daudé


On 3/20/20 12:39 PM, Cornelia Huck wrote:

On Wed, 18 Mar 2020 23:27:15 +0100
Philippe Mathieu-Daudé  wrote:


Similarly to commit 4f370b1098, test-util-sockets fails in
restricted non-x86 Travis containers since they apparently
blacklisted some required system calls there.


Is "they" == "Travis admins"? Can we get them to remove those calls
from the blacklist?


I suppose, I copy/pasted Thomas's description from commit 4f370b1098.

No clue, but we can try :)



(I'm wondering why x86 allows those calls. Probably just because it has
been around for longer.)


Let's simply skip the test if we detect such an environment.

Reviewed-by: Daniel P. Berrangé 
Signed-off-by: Philippe Mathieu-Daudé 
---
  tests/test-util-sockets.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/tests/test-util-sockets.c b/tests/test-util-sockets.c
index 5fd947c7bf..046ebec8ba 100644
--- a/tests/test-util-sockets.c
+++ b/tests/test-util-sockets.c
@@ -231,11 +231,18 @@ static void test_socket_fd_pass_num_nocli(void)
  int main(int argc, char **argv)
  {
  bool has_ipv4, has_ipv6;
+char *travis_arch;
  
  socket_init();
  
  g_test_init(&argc, &argv, NULL);
  
+travis_arch = getenv("TRAVIS_CPU_ARCH");

+if (travis_arch && !g_str_equal(travis_arch, "x86_64")) {
+g_printerr("Test does not work on non-x86 Travis containers.");
+goto end;
+}
+
  /* We're creating actual IPv4/6 sockets, so we should
   * check if the host running tests actually supports
   * each protocol to avoid breaking tests on machines

Re: [PATCH 0/3] iotests: Fix intermittent 030 hang

2020-03-22 Thread Peter Maydell

On Fri, 13 Mar 2020 at 08:37, Kevin Wolf  wrote:
>
> Peter ran into a 030 hang while testing a pull request. This turned out
> to be two bugs in the test suite at once: First was the test failing
> because a timeout was apparently too short, second was that the timeout
> would actually cause the test to hang instead of failing. This series
> should fix both.
>
> Kevin Wolf (3):
>   iotests.py: Enable faulthandler
>   python/qemu: Kill QEMU process if 'quit' doesn't work
>   iotests: Increase pause_wait() timeout
>
>  python/qemu/machine.py| 1 +
>  tests/qemu-iotests/iotests.py | 5 -
>  2 files changed, 5 insertions(+), 1 deletion(-)

Applied to master since I've been seeing this hang off-and-on.

thanks
-- PMM

Re: [PATCH v3 10/16] hw/i386/vmport: Add support for CMD_GETTIME

2020-03-22 Thread Liran Alon

On 15/03/2020 13:56, Liran Alon wrote:

On 14/03/2020 22:56, Michael S. Tsirkin wrote:

On Sat, Mar 14, 2020 at 10:05:20PM +0200, Liran Alon wrote:

Michael, you can also refer to this VMware time-keeping whitepaper:
https://urldefense.com/v3/__https://www.vmware.com/pdf/vmware_timekeeping.pdf__;!!GqivPVa7Brio!K8sfnfvVgKwrQ4SMwX-K6-S5yR4ln9_qZ6o4GzIpQkohfWtinlplNhXzFlyUgks$
.

According to section "Initializing and Correcting Wall-Clock Time":
"""
VMware Tools can also optionally be used to correct long‐term drift and
errors by periodically
resynchronizing the virtual machine’s clock to the host’s clock, but
the

current version at this writing is limited.
In particular, in guest operating systems other than NetWare, it
does not

correct errors in which the guest clock
is ahead of real time, only those in which the guest clock is behind.

"""

This talks about guest time.
What this does not mention is whether hosts need to employ any
mechanisms

to synchronise wall clock between hosts.
The above mentioned whitepaper also discuss how VMware maintains the
wallclock time across migrations (vMotion).

See section "Using VMware Tools Clock Synchronization" in whitepaper.

Specifically, there is an option in .vmx file named
"time.synchronize.resume.disk" which:

"""
If set to TRUE, the clock syncs after resuming from suspend and after
migrating to a new host using the VMware VMotion feature.

"""

The matching functionality in open-vm-tools can can be seen in
services/plugins/timeSync/timeSync.c where ToolsOnLoad()
registers the "Time_Synchronize" RpcCallback, which is
TimeSyncTcloHandler(), that is possibly allowed to sync time backwards
(Note the "backwardSync" var).

The current patch-series I have submitted doesn't implement this
RpcCallback functionality.
That work can be delayed to a future patch-series that will add this
extra functionality as-well.

If I understand correctly, this seems to validate my assumption that
current

implementation for CMD_GETTIME is sufficient.

So I am concerned this does not interact well with other time sources
in QEMU. For example, it's very useful to set guest time with -rtc base
flag.

Can you use qemu_get_timedate?

This is a very good point.
VMware also have the ability that allows user to explicitly set guest
time with .vmx "rtc.startTime" option.
(The time-zone can also be set by specifying an offset from UTC with
"rtc.diffFromUTC" option)

However, if you will read section "Using VMware Tools Clock
Synchronization -> Disabling All Synchronization" in above mentioned
whitepaper,
you will notice that in VMware's design, VMPort CMD_GETTIME command is
intentionally not synced with virtual CMOS TOD. i.e. The section
explicitly
documents that if a user wants to set guest time to fictitious time,
user must disable VMware Tools time sync functionality by manipulating
"tools.syncTime" and "time.synchronize.*" configuration options as
desired.

Therefore, I think current patch VMPort CMD_GETTIME command
implementation is correct.

What do you think?

-Liran

Gentle ping.

I would like to send the next version of the patch-series.
But before I do, I would like to know what we have agreed upon regarding
this patch.

Thanks,
-Liran

Re: In tree configure errors since 6116aea9

2020-03-22 Thread BALATON Zoltan


On Sun, 22 Mar 2020, Laurent Vivier wrote:

Le 21/03/2020 à 19:31, BALATON Zoltan a écrit :

On Sat, 21 Mar 2020, Laurent Vivier wrote:

Le 21/03/2020 à 18:29, BALATON Zoltan a écrit :

Hello,

Since 6116aea99, or actually 4d6a835d (linux-user: introduce parameters
to generate syscall_nr.h) but only next commit starts to enable it I get
these errors when running configure in source tree:

grep: ./.gitlab-ci.d: Is a directory
grep: ./scripts/qemu-guest-agent/fsfreeze-hook.d: Is a directory

for each entry in that loop over arches. Could this be silenced?


I didn't see that because I always do an out-of-tree build.


Isn't there a test for that or should there be one?


Could you try this?

--- a/configure
+++ b/configure
@@ -1911,6 +1911,7 @@ for arch in alpha hppa m68k xtensa sh4 microblaze
arm ppc s390x sparc sparc64 \
    rm -f "${source_path}/linux-user/${arch}/syscall_nr.h"
    # remove the dependency files
    find . -name "*.d" \
+   -type f \
   -exec grep -q
"${source_path}/linux-user/${arch}/syscall_nr.h" {} \; \
   -exec rm {} \;
done


This gets rid of the errors but seems to be much slower:

with 4d6a835d running my usual configure script:

real    0m5.968s
user    0m4.642s
sys    0m1.402s

with HEAD and above patch:

real    0m20.246s
user    0m14.143s
sys    0m6.152s

Given that configure is rerun when some files change if there's a way to
get at least the previous speed back might be better if possible.

Regards,
BALATON Zoltan


Could you try this:

--- a/configure
+++ b/configure
@@ -1910,9 +1910,9 @@ for arch in alpha hppa m68k xtensa sh4 microblaze
arm ppc s390x sparc sparc64 \
# remove the file if it has been generated in the source directory
rm -f "${source_path}/linux-user/${arch}/syscall_nr.h"
# remove the dependency files
-find . -name "*.d" \
-   -exec grep -q
"${source_path}/linux-user/${arch}/syscall_nr.h" {} \; \
-   -exec rm {} \;
+test -d ${arch}-linux-user && find ${arch}-linux-user -type f -name
"*.d" \
+ -exec grep -q "${source_path}/linux-user/${arch}/syscall_nr.h"
{} \; \
+ -exec rm {} \;
done


This is better, runs in 6-8 seconds. Thanks.

Regards,
BALATON Zoltan

[PATCH-for-5.0 v2 0/4] tests/docker: Fixes for 5.0

2020-03-22 Thread Philippe Mathieu-Daudé

Easy fixes for our Docker images.

Since v1:
- Reword gcrypt patch description (requested by Aleksandar)

Philippe Mathieu-Daudé (4):
  tests/docker: Keep package list sorted
  tests/docker: Install gcrypt devel package in Debian image
  tests/docker: Use Python3 PyYAML in the Fedora image
  tests/docker: Add libepoxy and libudev packages to the Fedora image

 tests/docker/dockerfiles/centos7.docker  |  6 --
 tests/docker/dockerfiles/debian-amd64.docker |  1 +
 tests/docker/dockerfiles/fedora.docker   | 10 +++---
 3 files changed, 12 insertions(+), 5 deletions(-)

-- 
2.21.1

[PATCH-for-5.0 v2 2/4] tests/docker: Install gcrypt devel package in Debian image

2020-03-22 Thread Philippe Mathieu-Daudé

In commit 6f8bbb374be we enabled building with the gcrypt library
on the the Debian 'x86 host', which was based on Debian Stretch.
Later in commit 698a71edbed we upgraded the Debian base image to
Buster.

Apparently Debian Stretch was listing gcrypt as a QEMU dependency,
but this is not the case anymore in Buster, so we need to install
it manually (it it not listed by 'apt-get -s build-dep qemu' in
the common debian10.docker anymore). This fixes:

 $ ../configure $QEMU_CONFIGURE_OPTS

  ERROR: User requested feature gcrypt
 configure was not able to find it.
 Install gcrypt devel >= 1.5.0

Signed-off-by: Philippe Mathieu-Daudé 
---
v2: Reword description, do not use 'Fixes:' tag (Aleksandar)
---
 tests/docker/dockerfiles/debian-amd64.docker | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/docker/dockerfiles/debian-amd64.docker 
b/tests/docker/dockerfiles/debian-amd64.docker
index d4849f509f..957f0bc2e7 100644
--- a/tests/docker/dockerfiles/debian-amd64.docker
+++ b/tests/docker/dockerfiles/debian-amd64.docker
@@ -16,6 +16,7 @@ RUN apt update && \
 apt install -y --no-install-recommends \
 libbz2-dev \
 liblzo2-dev \
+libgcrypt20-dev \
 librdmacm-dev \
 libsasl2-dev \
 libsnappy-dev \
-- 
2.21.1

[PATCH-for-5.0 v2 1/4] tests/docker: Keep package list sorted

2020-03-22 Thread Philippe Mathieu-Daudé

Keep package list sorted, this eases rebase/cherry-pick.

Fixes: 3a6784813
Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/docker/dockerfiles/centos7.docker | 6 --
 tests/docker/dockerfiles/fedora.docker  | 6 --
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/tests/docker/dockerfiles/centos7.docker 
b/tests/docker/dockerfiles/centos7.docker
index cdd72de7eb..9a2a2e515d 100644
--- a/tests/docker/dockerfiles/centos7.docker
+++ b/tests/docker/dockerfiles/centos7.docker
@@ -2,6 +2,8 @@ FROM centos:7
 RUN yum install -y epel-release centos-release-xen-48
 
 RUN yum -y update
+
+# Please keep this list sorted alphabetically
 ENV PACKAGES \
 bison \
 bzip2 \
@@ -19,6 +21,7 @@ ENV PACKAGES \
 libepoxy-devel \
 libfdt-devel \
 librdmacm-devel \
+libzstd-devel \
 lzo-devel \
 make \
 mesa-libEGL-devel \
@@ -33,7 +36,6 @@ ENV PACKAGES \
 tar \
 vte-devel \
 xen-devel \
-zlib-devel \
-libzstd-devel
+zlib-devel
 RUN yum install -y $PACKAGES
 RUN rpm -q $PACKAGES | sort > /packages.txt
diff --git a/tests/docker/dockerfiles/fedora.docker 
b/tests/docker/dockerfiles/fedora.docker
index a658c0..019eb12dcb 100644
--- a/tests/docker/dockerfiles/fedora.docker
+++ b/tests/docker/dockerfiles/fedora.docker
@@ -1,4 +1,6 @@
 FROM fedora:30
+
+# Please keep this list sorted alphabetically
 ENV PACKAGES \
 bc \
 bison \
@@ -38,6 +40,7 @@ ENV PACKAGES \
 libubsan \
 libusbx-devel \
 libxml2-devel \
+libzstd-devel \
 llvm \
 lzo-devel \
 make \
@@ -92,8 +95,7 @@ ENV PACKAGES \
 vte291-devel \
 which \
 xen-devel \
-zlib-devel \
-libzstd-devel
+zlib-devel
 ENV QEMU_CONFIGURE_OPTS --python=/usr/bin/python3
 
 RUN dnf install -y $PACKAGES
-- 
2.21.1

[PATCH-for-5.0 v2 3/4] tests/docker: Use Python3 PyYAML in the Fedora image

2020-03-22 Thread Philippe Mathieu-Daudé

The Python2 PyYAML is now pointless, switch to the Python3 version.

Fixes: bcbf27947 (docker: move tests from python2 to python3)
Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/docker/dockerfiles/fedora.docker | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/docker/dockerfiles/fedora.docker 
b/tests/docker/dockerfiles/fedora.docker
index 019eb12dcb..174979c7af 100644
--- a/tests/docker/dockerfiles/fedora.docker
+++ b/tests/docker/dockerfiles/fedora.docker
@@ -79,8 +79,8 @@ ENV PACKAGES \
 perl-Test-Harness \
 pixman-devel \
 python3 \
+python3-PyYAML \
 python3-sphinx \
-PyYAML \
 rdma-core-devel \
 SDL2-devel \
 snappy-devel \
-- 
2.21.1

[PATCH-for-5.0 v2 4/4] tests/docker: Add libepoxy and libudev packages to the Fedora image

2020-03-22 Thread Philippe Mathieu-Daudé

Install optional dependencies of QEMU to get better coverage.

Suggested-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/docker/dockerfiles/fedora.docker | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/docker/dockerfiles/fedora.docker 
b/tests/docker/dockerfiles/fedora.docker
index 174979c7af..4bd2c953af 100644
--- a/tests/docker/dockerfiles/fedora.docker
+++ b/tests/docker/dockerfiles/fedora.docker
@@ -29,6 +29,7 @@ ENV PACKAGES \
 libblockdev-mpath-devel \
 libcap-ng-devel \
 libcurl-devel \
+libepoxy-devel \
 libfdt-devel \
 libiscsi-devel \
 libjpeg-devel \
@@ -38,6 +39,7 @@ ENV PACKAGES \
 libseccomp-devel \
 libssh-devel \
 libubsan \
+libudev-devel \
 libusbx-devel \
 libxml2-devel \
 libzstd-devel \
-- 
2.21.1

1 2 >

1 - 100 of 113 matches

Mail list logo