[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 00/13] tests/vm: serial console autoinstall, mis

From: Thomas Huth
Subject: Re: [Qemu-devel] [PATCH 00/13] tests/vm: serial console autoinstall, misc fixes.
Date: Thu, 9 May 2019 13:53:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 08/05/2019 10.56, Gerd Hoffmann wrote:
> This patch series changes the way virtual machines for test builds are
> managed.  They are created locally on the developer machine now.  The
> installer is booted on the serial console and the scripts walks through
> the dialogs to install and configure the guest.
> That takes the download.patchew.org server out of the loop and makes it
> alot easier to tweak the guest images (adding build dependencies for
> example).
> The install scripts take care to apply host proxy settings (from *_proxy
> environment variables) to the guest, so any package downloads will be
> routed through the proxy and can be cached that way.  This also makes
> them work behind strict firewalls.
> There are also a bunch of smaller tweaks for tests/vm to fix issues I
> was struggling with.  See commit messages of individual patches for
> details.
> Known issue:  NetBSD package install is not working for me right now.
> It did work a while ago.  Not sure what is going on here.

I now gave your series another try and replaced patch 3 with the python3
fix from Eduardo locally here. FreeBSD works great. OpenBSD is fine too,
except for the known issue that the "gmake check" does not work - but
this issue has been there before already. NetBSD also does not work for
me, so I guess you should hold off that patch for now?

So for patches 1, 2 and 4 - 10 (I did not check the Linux images yet):

Tested-by: Thomas Huth <address@hidden>

> Do we have accelerator support for the BSDs?  A "make check" for a full
> build takes ages, and I suspect tcg being used is part of the problem.
> I did my tests using "TARGET_LIST=x86_64-softmmu" because of that.

I think they should be running with "--enable-kvm". Did you make sure
that you've enabled multiple CPUs with J=8 for example? ... but for me,
the compilation is also quite a bit slower, indeed. I think part of the
problem might be clang which is compiling a little bit slower than GCC
as far as I know...?


reply via email to

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