qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL v3 00/13] qemu-ga patch queue


From: Michael Roth
Subject: Re: [Qemu-devel] [PULL v3 00/13] qemu-ga patch queue
Date: Mon, 19 Oct 2015 07:44:13 -0500
User-agent: alot/0.3.6

Quoting Peter Maydell (2015-10-18 16:21:30)
> On 17 October 2015 at 17:59, Michael Roth <address@hidden> wrote:
> > Hi Peter,
> >
> > Please note that 'glib-compat: add 2.38/2.40/2.46 asserts' is also in
> > Marc-André's recent ivshmem PULL. The 2 versions of the patches are 
> > identical,
> > but let me know if you'd prefer a re-send/re-base later.
> >
> > The following changes since commit 6d57410a79d51d92673c54f26624b44f27fa6214:
> >
> >   Merge remote-tracking branch 
> > 'remotes/pmaydell/tags/pull-target-arm-20151016' into staging (2015-10-17 
> > 12:31:33 +0100)
> >
> > are available in the git repository at:
> >
> >
> >   git://github.com/mdroth/qemu.git tags/qga-pull-2015-10-14-v3-tag
> >
> > for you to fetch changes up to ed9f1986d19c2d21667a14b875b2ac8b8a19b8a5:
> >
> >   qga: fix uninitialized value warning for win32 (2015-10-17 11:24:27 -0500)
> >
> > ----------------------------------------------------------------
> > qemu-ga patch queue
> >
> > * add unit tests for qemu-ga
> > * add guest-exec support for posix/w32 guests
> > * added 'qemu-ga' target for w32. this allows us to do full MSI build,
> >   without overloading 'qemu-ga.exe' target with uneeded dependencies.
> > * number of s/g_new/g_malloc/ conversions for qga
> >
> > v2:
> > * commit message and qapi documentation spelling fixes
> > * rename 'inp-data' guest-exec param to 'input-data'
> >
> > v3:
> > * fix OSX build errors for test-qga by using PRId64
> >   format in place of glib's, and dropping use of G_SPAWN_DEFAULT
> >   macro for glib 2.22 compat
> > * fix win32 build warnings for 32-bit builds by avoid int casts
> >   of process HANDLEs
> 
> Still seeing failures, I'm afraid.
> 
> OSX assertion failures:
> 
> GTESTER tests/test-qga
> **
> ERROR:/Users/pm215/src/qemu-for-merges/tests/libqtest.c:238:void
> socket_send(int, const char *, size_t): assertion failed (len != -1):
> (-1 != -1)
> GTester: last random seed: R02S96655a200709f74b72ea42792cd65e8e

Argh, sorry for all this noise.

I suspect what's happening is qemu-ga itself might be failing to load or
bind to the socket, and there appears to be a bug in the test case where
we don't check for an fd == -1 return value in connect_qga(), so probably
end up trying to write to it later.

As far as why qemu-ga doesn't appear to be loading properly under OSX,
I think I need to get an environment set up somewhere to debug. I tried
to get an OSX guest going but apparently you need to own an OSX box to
get a AppleSMC OSK key so I'll have to hold off on that for now.

This isn't really something I think has been tested or deployed very
often outside of linux/w32 guests (and w32 isn't enabled since
interacting with a qemu-ga under wine/binfmt requires a specialized
wine environment), so for now I think the best option is to run test-qga
under CONFIG_LINUX instead of CONFIG_POSIX.

> 
> (repeated about 10 times).
> 
> Test failures on 64-bit ARM:
> TEST: tests/test-qga... (pid=22454)
>   /qga/sync-delimited:                                                 OK
>   /qga/sync:                                                           OK
>   /qga/ping:                                                           OK
>   /qga/info:                                                           OK
>   /qga/network-get-interfaces:                                         OK
>   /qga/get-vcpus:                                                      OK
>   /qga/get-fsinfo:                                                     OK
>   /qga/get-memory-block-info:                                          **
> ERROR:/home/petmay01/qemu/tests/test-qga.c:294:test_qga_get_memory_block_info:
> assertion failed ret: GenericError
> open("/sys/devices/system/memory/"): No such file or directory
> FAIL
> GTester: last random seed: R02S6aa3e1f8b691a9900d2ea9945e79869d
> (pid=22458)
>   /qga/get-memory-blocks:                                              **
> ERROR:/home/petmay01/qemu/tests/test-qga.c:313:test_qga_get_memory_blocks:
> assertion failed ret: GenericError Can't open
> directory"/sys/devices/system/memory/"
> : No such file or directory
> FAIL
> GTester: last random seed: R02S978afb04187410dc690a8b7d6d236793
> (pid=22461)
>   /qga/file-ops:                                                       OK
>   /qga/get-time:                                                       OK
>   /qga/invalid-cmd:                                                    OK
>   /qga/fsfreeze-status:                                                OK
>   /qga/blacklist:                                                      OK
>   /qga/config:                                                         OK
> FAIL: tests/test-qga
> make: *** [check-tests/test-qga] Error 1
> 
> Not sure why it's complaining, /sys/devices/system/memory/ does
> exist on this box.
> 
> Ditto on 32-bit ARM, though that's not surprising as it's just
> a chroot on an equivalently-configured machine to the 64-bit build.

Hmm, I'm have FC22 running via -machine vexpress-a15 and I see the same
error, but in my case /sys/devices/system/memory *is* actually missing:

address@hidden qemu-build]$ uname -a
Linux localhost 4.0.4-301.fc22.armv7hl #1 SMP Thu May 21 14:37:41 UTC 2015 
armv7l armv7l armv7l GNU/Linux
address@hidden qemu-build]$ ls /sys/devices/
armv7_cortex_a15  breakpoint  platform  software  system  tracepoint virtual
address@hidden qemu-build]$ ls /sys/devices/system/
clockevents  clocksource  container  cpu
address@hidden qemu-build]$

I didn't see any config option to disable creation of that sysfs node
so I'm a bit confused...

But given such systems exist I think the right fix is to have
guest-get-memory-block-info return an empty-list rather than error in this
case.

I think that would fix the case you're describing, but only by luck.
Probably the best we can do for now though...


Will send a v4 with these changes unless anyone has any other
suggestions.

> 
> thanks
> -- PMM
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]