Re: [PATCH v1 01/11] configure: don't override the selected host test compiler if defined

[Ed Maste]

On Fri, 17 Sept 2021 at 12:27, Alex Bennée  wrote:
>
> There are not many cases you would want to do this but one is if you
> want to use a test friendly compiler like gcc instead of a system
> compiler like clang. Either way we should honour the users choice if
> they have made it.

A little bit of a tangent, but I'm curious about this comment - what
aspects of GCC make it more test friendly? (I help maintain LLVM tools
on FreeBSD, and would like to make sure they provide as good an
experience as possible.)

Re: Rust in Qemu BoF followup: Rust vs. qemu platform support

[Ed Maste]

On Mon, 20 Sept 2021 at 01:14, David Gibson  wrote:
>
> I've updated my table entry to N/A on that basis.  Thanks for the
> clarification, this wasn't obvious to me from
> https://www.freebsd.org/platforms/ (it says "Tier 4", without
> explaining what that means).

That is indeed a bit confusing. If you click on the "Support Tier"
link (in the table heading) it's documented as:

21.6. Tier 4: Unsupported Architectures
Tier 4 platforms are not supported in any form by the project.

We (FreeBSD) should really just remove that and replace Tier 4 with unsupported.

> Might be worth talking to the Rust people as well, to see if you can
> get a promotion from Tier3 to Tier2.

Yes, good idea. I've had discussions with a few Arm folks about
improving the rust tier for FreeBSD/arm64, but should do this for
x86_64 as well.

Re: [PATCH v0] kvm: unsigned datatype in ioctl wrapper

[Ed Maste]

On Mon, 30 Aug 2021 at 13:34, Peter Maydell  wrote:
>
> # As noted, this does not actually cause problems on Linux, because
> # unlike FreeBSD, Linux knows what the f*ck it is doing, and just
> # ignores the upper bits exactly because of possible sign confusion.
>
> Whether that's still true a decade later I have no idea :-)

It wasn't even true a decade ago -- FreeBSD has ignored the upper bits
since 2005[1]. That change included a warning if upper bits were set,
but the warning is now hidden behind a diagnostic option.

[1] URL: 
https://cgit.FreeBSD.org/src/commit/?id=9fc6aa0618a174f436fb1a26867c99cff4125b40

Re: [PATCH v1 21/22] cirrus: use V=1 when running tests on FreeBSD and macOS

[Ed Maste]

On Wed, 7 Oct 2020 at 12:09, Alex Bennée  wrote:
>
> From: Paolo Bonzini 
>
> Using "V=1" makes it easier to identify hanging tests, especially
> since they are run with -j1.  It is already used on Windows builds,
> do the same for FreeBSD and macOS.
>
> Signed-off-by: Paolo Bonzini 
> Signed-off-by: Alex Bennée 
> Reviewed-by: Philippe Mathieu-Daudé 
> Message-Id: <20201007140103.711142-1-pbonz...@redhat.com>
Reviewed-by: Ed Maste 

Re: [PATCH v2 6/8] qemu/bswap: Use compiler __builtin_bswap() on FreeBSD

[Ed Maste]

On Mon, 28 Sep 2020 at 09:20, Philippe Mathieu-Daudé  wrote:
>
> Since commit efc6c070aca ("configure: Add a test for the minimum
> compiler version") the minimum compiler version required for GCC
> is 4.8, which supports __builtin_bswap().
> Remove the FreeBSD specific ifdef'ry.
>
> This reverts commit de03c3164accc21311c39327601fcdd95da301f3
> ("bswap: Fix build on FreeBSD 10.0").
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Ed Maste 

Aside, to test building with this change on Clang 11 (default compiler
in FreeBSD-CURRENT) I needed a few other changes to avoid warnings:

hw/s390x/ipl.h, hw/usb/dev-uas.c variable sized type warnings

../hw/usb/dev-uas.c:157:31: error: field 'status' with variable sized
type 'uas_iu' not at the end of a struct or class is a GNU extension
[-Werror,-Wgnu-variable-sized-type-not-at-end]
uas_iustatus;
  ^

target/s390x/cpu_models.c pointer to smaller integer type cast

../target/s390x/cpu_models.c:984:21: error: cast to smaller integer
type 'S390Feat' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
S390Feat feat = (S390Feat) opaque;
^

Re: [PATCH v2 0/7] hw/char/serial: Housekeeping

[Ed Maste]

On Sat, 12 Sep 2020 at 07:46,  wrote:
>
> Patchew URL: https://patchew.org/QEMU/20200912114040.918464-1-f4...@amsat.org/
>
> Hi,
>
> This series failed build test on FreeBSD host. Please find the details below.
>
> The full log is available at
> http://patchew.org/logs/20200912114040.918464-1-f4...@amsat.org/testing.FreeBSD/?type=message.

Looks like a full disk:

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
>From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20200912114040.918464-1-f4...@amsat.org
-> patchew/20200912114040.918464-1-f4...@amsat.org
error: copy-fd: write returned No space left on device
fatal: failed to copy file to
'/var/tmp/patchew-tester-tmp-b6phottt/src/.git/objects/pack/pack-7bdf4f5a855cab7e92327c9c14876dca81c24a36.pack':
No space left on device
fatal: The remote end hung up unexpectedly

Re: [PATCH v2 14/21] cirrus: Building freebsd in a single short

[Ed Maste]

On Wed, 9 Sep 2020 at 05:47, Yonggang Luo  wrote:
>
> freebsd 1 hour limit not hit anymore
>
> Signed-off-by: Yonggang Luo 

Reviewed-by: Ed Maste 

> When its running properly, the consumed time are little, but when tests 
> running too long,
> look at the cpu  usage, the cpu usage are nearly zero. does't consuming time.

So it looks like we have a test getting stuck. After this change is in
we could split the test execution out into its own script so to make
it more obvious if/when this happens - for example,

  script:
- mkdir build
- cd build
- ../configure --enable-werror || { cat config.log; exit 1; }
- gmake -j8
  test_script:
   - gmake V=1 check

I can follow up with a proper patch for that (and making the change
for macos as well) later.

Re: [PATCH 3/3] cirrus.yml: Update the macOS jobs to Catalina

[Ed Maste]

On Fri, 24 Jul 2020 at 10:32, Thomas Huth  wrote:
>
> When looking at the CI jobs on cirrus-ci.com, it seems like the mojave-based
> images have been decomissioned a while ago already, since apparently all our
> jobs get automatically upgraded to catalina. So let's update our YML script
> accordingly to avoid confusion.
>
> Signed-off-by: Thomas Huth 

Reviewed-by: Ed Maste 

Re: [PATCH 2/3] cirrus.yml: Compile macOS and FreeBSD with -Werror

[Ed Maste]

On Fri, 24 Jul 2020 at 10:32, Thomas Huth  wrote:
>
> Compiler warnings currently go unnoticed in our FreeBSD and macOS builds,
> since -Werror is only enabled for Linux and MinGW builds by default. So
> let's enable them here now, too.

Reviewed-by: Ed Maste 

for the FreeBSD change; I'm indifferent on which method is used to
address the macos deprecation warnings.

Re: [PATCH v3 00/19] mailmap: Add more entries to sanitize 'git log' output

[Ed Maste]

On Thu, 2 Jul 2020 at 14:12,  wrote:
>
> Patchew URL: https://patchew.org/QEMU/20200702173818.14651-1-f4...@amsat.org/
>
> Hi,
>
> This series failed build test on FreeBSD host. Please find the details below.

I had a look at this (because it's a FreeBSD report); it appears to
have been a temporary connectivity issue.

> fatal: unable to access 'https://github.com/patchew-project/qemu/': Failed 
> connect to github.com:443; Connection timed out

Re: [Qemu-devel] [PULL 11/13] tests/qemu-iotests: Do not hard-code the path to bash

[Ed Maste]

On Tue, 21 May 2019 at 07:04, Thomas Huth  wrote:
>
> bash is installed in a different directory on non-Linux systems like
> FreeBSD. Do not hard-code /bin/bash here so that the tests can run
> there, too.
>
> Reviewed-by: Eric Blake 
> Reviewed-by: Philippe Mathieu-Daudé 
> Reviewed-by: Alex Bennée 
> Acked-by: Christian Borntraeger 
> Message-Id: <20190502084506.8009-4-th...@redhat.com>
> Signed-off-by: Thomas Huth 

Reviewed-by: Ed Maste 

Re: [Qemu-devel] [PATCH v3 05/14] tests/vm: run test builds on snapshot

[Ed Maste]

On Mon, 20 May 2019 at 08:47, Gerd Hoffmann  wrote:
>
> The build script doesn't shutdown the guest VMs properly,
> which results in filesystem corruption and guest boot
> failures sooner or later.
>
> Use the --snapshot to run builds on a snapshot,
> That way killing the VM doesn't corrupt the base image.
>
> Signed-off-by: Gerd Hoffmann 
> Tested-by: Thomas Huth 

Acked-by: Ed Maste 

Re: [Qemu-devel] [PATCH v6 1/4] VirtIO-RNG: Update default entropy source to `/dev/urandom`

[Ed Maste]

On Tue, 21 May 2019 at 10:15, Laurent Vivier  wrote:
>
> From: Kashyap Chamarthy 
>
> [...]
>
> Given the above, change the entropy source for VirtIO-RNG device to
> `/dev/urandom`.
>
> Related discussion in these[1][2] past threads.
>
> [1] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg08335.html
> -- "RNG: Any reason QEMU doesn't default to `/dev/urandom`?"
> [2] https://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg02724.html
> -- "[RFC] Virtio RNG: Consider changing the default entropy source to
>/dev/urandom"
>
> Signed-off-by: Kashyap Chamarthy 
> Reviewed-by: Daniel P. Berrangé 
> Reviewed-by: Stefan Hajnoczi 
> Reviewed-by: Markus Armbruster 
> Signed-off-by: Laurent Vivier 

Acked-by: Ed Maste 

Re: [Qemu-devel] [PULL 13/13] tests/qemu-iotests: Remove the "_supported_os Linux" line from many tests

[Ed Maste]

On Tue, 21 May 2019 at 07:06, Thomas Huth  wrote:
>
> A lot of tests run fine on FreeBSD and macOS, too - the limitation
> to Linux here was likely just copied-and-pasted from other tests.
> Thus remove the "_supported_os Linux" line from tests that run
> successful in our CI pipelines on FreeBSD and macOS.
>
> Reviewed-by: Alex Bennée 
> Tested-by: Alex Bennée 
> Acked-by: Christian Borntraeger 
> Message-Id: <20190502084506.8009-6-th...@redhat.com>
> Signed-off-by: Thomas Huth 

Acked-by: Ed Maste 

Re: [Qemu-devel] [PATCH] cirrus.yml: Add macOS continuous integration task

[Ed Maste]

On Mon, 4 Mar 2019 at 07:11, Philippe Mathieu-Daudé  wrote:
>
> On 3/4/19 11:32 AM, Thomas Huth wrote:
> > cirrus-ci.com also has the possibility to run CI tasks on macOS.
> > Since most of the QEMU developers do not have access to macOS yet,
> > let's add a CI pipeline for this operating system here, too.
>
> > Signed-off-by: Thomas Huth 
> Reviewed-by: Philippe Mathieu-Daudé 
Acked-by: Ed Maste 

Re: [Qemu-devel] [PATCH] cirrus.yml: Add macOS continuous integration task

[Ed Maste]

On Mon, 4 Mar 2019 at 06:39, Thomas Huth  wrote:
> >
> > Can we get report of failures? (IRC, mail to ML, patchew icon)
>
> Honestly, I've got no clue ... this is the only help text that I've
> found so far:
>
>  https://cirrus-ci.org/guide/notifications/

I asked on twitter and was pointed at that same link, which in turn
leads to https://github.com/cirrus-actions/email but I'm not quite
sure what to do with it.

Re: [Qemu-devel] [PATCH v3] .cirrus.yml: basic compile and test for FreeBSD

[Ed Maste]

On Tue, 22 Jan 2019 at 04:40, Thomas Huth  wrote:
>
> Then I finally increased the CPUs back to 8 again, but stick with 8G of
> RAM, and that indeed finished in time successfully:
>
>  https://cirrus-ci.com/build/6218565876187136
>
> So yes, looks like 8 CPUs should work indeed, but I think you should
> decrease the amount of memory of the VM, to make sure that it does not
> get killed so easily. 8 GB of RAM should also be enough to compile QEMU,
> as far as I can tell.

Ok. I think Cirrus-CI might be having some growing pains.

I can submit a v4 patch with 8G for the VM and V=1 only on the tests,
then after it gets merged keep an eye on results for a while before we
consider enabling build notifications etc.

Re: [Qemu-devel] [PATCH v3] .cirrus.yml: basic compile and test for FreeBSD

[Ed Maste]

On Mon, 21 Jan 2019 at 10:16, Ed Maste  wrote:
>
> To confirm, I have another build running now with
> echo "Running with hw.ncpu=$(sysctl -n hw.ncpu)"
> added.

Confirmed - https://cirrus-ci.com/build/5768962257190912:
Running with hw.ncpu=8

If there is some sort of hanging test issue I could try wrapping it in
timeout and outputting ps and other info upon failure.

Re: [Qemu-devel] [PATCH v3] .cirrus.yml: basic compile and test for FreeBSD

[Ed Maste]

On Mon, 21 Jan 2019 at 06:03, Alex Bennée  wrote:
>
> I should be able to add CirrusCI to the QEMU project github when we
> merge. I see there is another revision coming in so I''ll wait for that
> before I queue it up.

Do you mean my eadd119 commit "cirrus: tail dmesg to see if this is
due to OOM"? I didn't intend to submit that (at least not in exactly
the current form); I added it while looking at what I believe was a
transient Cirrus failure.

Re: [Qemu-devel] [PATCH v3] .cirrus.yml: basic compile and test for FreeBSD

[Ed Maste]

On Mon, 21 Jan 2019 at 05:18, Thomas Huth  wrote:
>
> Actually, scratch that Tested-by: My build timed out after 1 hour:
>
>  https://cirrus-ci.com/task/5113243459649536

Interesting. My build reports successful completion after a bit under
1/2 hr: https://cirrus-ci.com/build/5717787416723456

I notice that both your failing result and my successful result have
as the last test:

PASS 57 test-hmp /aarch64/hmp/none+2MB

so I wonder if yours actually finished in 1/2 hr, but then waited for
1/2 hr on something that got stuck?

> Are you also sure that you can run with 8 CPUs here? ... I somehow doubt
> that, otherwise the build should not take more than 1 h, I think.

To confirm, I have another build running now with
echo "Running with hw.ncpu=$(sysctl -n hw.ncpu)"
added.

Re: [Qemu-devel] [PATCH v2] .cirrus.yml: basic compile and test for FreeBSD

[Ed Maste]

On Thu, 17 Jan 2019 at 01:28, Thomas Huth  wrote:
>
> > +bison curl cyrus-sasl fontconfig freetype2 git glib gmake gnutls
>
> I'm still wondering why you need fontconfig and freetype2 here?

They must have crept in from previous experimentation; confirmed still
builds and tests pass on FreeBSD without them. New patch coming.

[Qemu-devel] [PATCH v2] .cirrus.yml: basic compile and test for FreeBSD

[Ed Maste]

From: Ed Maste 

Signed-off-by: Ed Maste 
Reviewed-by: Alex Bennée 
---
 .cirrus.yml | 16 
 MAINTAINERS |  8 
 2 files changed, 24 insertions(+)
 create mode 100644 .cirrus.yml

diff --git a/.cirrus.yml b/.cirrus.yml
new file mode 100644
index 00..df39d8e573
--- /dev/null
+++ b/.cirrus.yml
@@ -0,0 +1,16 @@
+freebsd_12_task:
+  freebsd_instance:
+image: freebsd-12-0-release-amd64
+cpu: 8
+memory: 24G
+  env:
+CIRRUS_CLONE_DEPTH: 1
+  install_script: pkg install -y
+bison curl cyrus-sasl fontconfig freetype2 git glib gmake gnutls
+nettle perl5 pixman pkgconf png usbredir
+  script:
+- mkdir build
+- cd build
+- ../configure || { cat config.log; exit 1; }
+- gmake -j8 V=1
+- gmake -j8 V=1 check
diff --git a/MAINTAINERS b/MAINTAINERS
index af339b86db..f9da8c9cf0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2483,6 +2483,14 @@ W: https://travis-ci.org/qemu/qemu
 W: https://app.shippable.com/github/qemu/qemu
 W: http://patchew.org/QEMU/
 
+FreeBSD Hosted Continuous Integration
+M: Ed Maste 
+M: Li-Wen Hsu 
+L: qemu-devel@nongnu.org
+S: Maintained
+F: .cirrus.yml
+W: https://cirrus-ci.com/github/qemu/qemu
+
 Guest Test Compilation Support
 M: Alex Bennée 
 R: Philippe Mathieu-Daudé 
-- 
2.20.1

Re: [Qemu-devel] [PATCH] .cirrus.yml: basic compile and test for FreeBSD

[Ed Maste]

On Wed, 16 Jan 2019 at 09:40, Alex Bennée  wrote:
>
> While debugging I ended up adding V=1 to the two gmake invocations
> because it wasn't quite clear why it had failed last time. With that:
>
> Reviewed-by: Alex Bennée 
>
> Does this patch come with an offer to be maintainer for FreeBSD/Cirrus
> CI stuff? In which case it will need a new entry in MAINTAINERS.

OK - I'll send a v2 with V=1 added and adding myself (and another
FreeBSD developer who's been adding FreeBSD Cirrus-CI support to a few
projects) to MAINTAINERS.

Re: [Qemu-devel] Hosted CI for FreeBSD - Cirrus CI

[Ed Maste]

On Tue, 15 Jan 2019 at 13:58, Ed Maste  wrote:
>
> From the log[1] it looks like it's building the libfdt from dtc/.
> Unfortunately I'm unable to dig in deeper into the hosted build (I
> have only the logs), and my local build attempts are currently failing
> due to unrelated issues. I'll investigate further as soon as I can.
>
> [1] https://cirrus-ci.com/task/6254685977575424

Somehow I had an unintended change in my branch where I added
.cirrus.yml that reverted the dtc submodule to the previous version.
With that fixed the build and test is successful on FreeBSD 12:
https://cirrus-ci.com/task/5528406336733184

Re: [Qemu-devel] [PATCH] .cirrus.yml: basic compile and test for FreeBSD

[Ed Maste]

On Tue, 15 Jan 2019 at 13:59, Marc-André Lureau
 wrote:
>
> Hi
>
> On Tue, Jan 15, 2019 at 10:42 PM Ed Maste  wrote:
> >
> > From: Ed Maste 
> >
> > Cirrus-CI (https://cirrus-ci.org) is a hosted CI service which supports
> > several platforms, including FreeBSD.  Later on we could build for other
> > hosts in Cirrus-CI, but I'm starting with only FreeBSD as it is not
> > supported by other CI services.
>
> Although I have never tested it, gitlab CI supports FreeBSD, macosx, 
> windows...

I haven't looked into it in great detail. As far as I can tell it
supports running tests on a provided FreeBSD instance via
gitlab-runner, and is not a fully hosted CI service like Cirrus-CI,
Travis, etc.

> What about patchew?

I'm also not very familiar with patchew. I did look at the three VM
BSD scripts (tests/vm/*bsd) reported in my Cirrus-CI thread, but am
not sure how they're invoked or how results are reported.

Re: [Qemu-devel] Hosted CI for FreeBSD - Cirrus CI

[Ed Maste]

On Tue, 15 Jan 2019 at 13:47, Peter Maydell  wrote:
> >
> > It looks like this was introduced between
> > 9b2e891ec5ccdb4a7d583b77988848282606fdea (works) and
> > 44ba6010635641a538c9b9b1f377dfa288751906 (fails). The .cirrus.yml file
> > in my branch is at least good enough to catch this sort of thing, so
> > I'll send the patch over (while trying to look into this).
>
> Commit fea35ca4b8e68b4fa updates our configure test to require
> a libfdt version that has fdt_check_full() in it, so in theory
> what is supposed to happen is that we will use the local
> version in dtc/ if the system libfdt is not new enough.
> Has that process gone wrong? Is the build using the system
> libfdt or the one we provide in the submodule ?

>From the log[1] it looks like it's building the libfdt from dtc/.
Unfortunately I'm unable to dig in deeper into the hosted build (I
have only the logs), and my local build attempts are currently failing
due to unrelated issues. I'll investigate further as soon as I can.

[1] https://cirrus-ci.com/task/6254685977575424

Re: [Qemu-devel] [PATCH] .cirrus.yml: basic compile and test for FreeBSD

[Ed Maste]

On Tue, 15 Jan 2019 at 13:42, Ed Maste  wrote:
>
> From: Ed Maste 

I'm not sure what part of the path between `git send-email` and the
list moved this From: into the message body, but it's not intentional.
If someone's going to pick up this patch please edit the commit
message.

> Cirrus-CI (https://cirrus-ci.org) is a hosted CI service which supports
> several platforms, including FreeBSD.  Later on we could build for other
...

[Qemu-devel] [PATCH] .cirrus.yml: basic compile and test for FreeBSD

[Ed Maste]

From: Ed Maste 

Cirrus-CI (https://cirrus-ci.org) is a hosted CI service which supports
several platforms, including FreeBSD.  Later on we could build for other
hosts in Cirrus-CI, but I'm starting with only FreeBSD as it is not
supported by other CI services.

Signed-off-by: Ed Maste 
---
 .cirrus.yml | 16 
 create mode 100644 .cirrus.yml

diff --git a/.cirrus.yml b/.cirrus.yml
new file mode 100644
index 00..ff4bf75ad1
--- /dev/null
+++ b/.cirrus.yml
@@ -0,0 +1,16 @@
+freebsd_12_task:
+  freebsd_instance:
+image: freebsd-12-0-release-amd64
+cpu: 8
+memory: 24G
+  env:
+CIRRUS_CLONE_DEPTH: 1
+  install_script: pkg install -y
+bison curl cyrus-sasl fontconfig freetype2 git glib gmake gnutls
+nettle perl5 pixman pkgconf png usbredir
+  script:
+- mkdir build
+- cd build
+- ../configure || { cat config.log; exit 1; }
+- gmake -j8
+- gmake -j8 check
-- 
2.20.1

Re: [Qemu-devel] Hosted CI for FreeBSD - Cirrus CI

[Ed Maste]

On Fri, 14 Dec 2018 at 09:57, Ed Maste  wrote:
>
> Indeed - having a hosted CI service to build on FreeBSD is something
> I've wanted for a long time; so much better if one service can support
> most or all platforms of interest.

My most recent test build with cirrus-ci
(https://cirrus-ci.com/github/emaste/qemu) failed with:
/usr/bin/ld: error: undefined symbol: fdt_check_full
>>> referenced by spapr_hcall.c:1797 
>>> (/tmp/cirrus-ci-build/hw/ppc/spapr_hcall.c:1797)
>>>   hw/ppc/spapr_hcall.o:(h_update_dt)
c++: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[1]: *** [Makefile:196: qemu-system-ppc64] Error 1
gmake: *** [Makefile:428: subdir-ppc64-softmmu] Error 2
gmake: *** Waiting for unfinished jobs

It looks like this was introduced between
9b2e891ec5ccdb4a7d583b77988848282606fdea (works) and
44ba6010635641a538c9b9b1f377dfa288751906 (fails). The .cirrus.yml file
in my branch is at least good enough to catch this sort of thing, so
I'll send the patch over (while trying to look into this).

Re: [Qemu-devel] Hosted CI for FreeBSD - Cirrus CI

[Ed Maste]

On Fri, 7 Dec 2018 at 04:54, Daniel P. Berrangé  wrote:
>
> Looking at this more generally I see they support Linux containers,
> native Windows containers, macOS and FreeBSD. IOW, they offer more
> platforms than our current Travis setup does and aren't stuck on an
> amcient Ubuntu version.

Indeed - having a hosted CI service to build on FreeBSD is something
I've wanted for a long time; so much better if one service can support
most or all platforms of interest.

> One key thing I can't find out is what, if any, limitations they put
> on resources used by the free service for OSS projects.  Does anyone
> know if they limit the number of concurrent build jobs like Travis
> does ? Do they put a fixed time limit on execution of a single job ?

I'm not sure what concurrency limits they have. I have empirically
discovered a 1hr limit for a job to complete, but I believe it can be
increased via the config file.

Re: [Qemu-devel] Hosted CI for FreeBSD - Cirrus CI

[Ed Maste]

On Thu, 6 Dec 2018 at 05:23, Daniel P. Berrangé  wrote:
>
> I'd encourage you to loook at installing as many deps as possible to
> maximise the coverage. eg gnutls, nettle, spice, and anything else that
> is relevant

I've now added: bison curl cyrus-sasl fontconfig freetype2 gnutls
nettle png usbredir
I think this should give a decent starting point and can post a patch
to add .cirrus.yml, then someone in the GitHub qemu organization would
have to add Cirrus CI for it to start running when commits happen.

> Are the Cirrus CI environments SMP ? If so adding a -j flag would
> give much improved build times.

For FreeBSD Cirrus CI spins up a VM (it doesn't run the test in a
jail/container) and supports a configurable CPU count. I changed it to
specify 8 vCPUs and ran a -j8 build/test in about 15 minutes - here's
a link to the run: https://cirrus-ci.com/task/6214818623127552

Re: [Qemu-devel] Hosted CI for FreeBSD - Cirrus CI

[Ed Maste]

On Wed, 5 Dec 2018 at 15:59, Kamil Rytarowski  wrote:
>
> There are already FreeBSD, OpenBSD and NetBSD test scripts in the qemu
> project.

I see scripts under tests/vm/ for FreeBSD, NetBSD, and OpenBSD, but
they're for testing BSD guests on QEMU, while I'm interested in
building and testing QEMU on a FreeBSD host. Is there something else
that I've missed?

[Qemu-devel] Hosted CI for FreeBSD - Cirrus CI

[Ed Maste]

I'd very much like to have CI coverage for QEMU on FreeBSD, and as of
yesterday there's a hosted CI service that supports FreeBSD: Cirrus
CI. They also offer free service for OSS projects. I created a
.cirrus.yml (shown below) in a QEMU GitHub fork and successfully
executed a build test.

I can submit a patch to add the config file, but wanted to ask for
advice or comments from those who set up the existing Linux CI first.
Is there anything I should be aware of or should address? Although
this is a very basic build / test I believe it will prove quite
valuable in reducing the latency between a commit and finding an issue
on FreeBSD.

.cirrus.yml:
freebsd_instance:
  image: freebsd-12-0-rc3-amd64

env:
  CIRRUS_CLONE_DEPTH: 1

task:
  install_script: pkg install -y git glib gmake perl5 pixman pkgconf
  script:
- mkdir build
- cd build
- ../configure || { cat config.log; exit 1; }
- gmake
- gmake check

Re: [Qemu-devel] [PATCH for-2.9? v4] ipmi: Fix macro issues

[Ed Maste]

On 31 March 2017 at 11:04, Eric Blake <ebl...@redhat.com> wrote:
>
> Might also be worth adding that an audit of the code finds no semantic
> change, that this is just cleaning up the compiler warning.

We should include core detail of your detailed analysis in such a
statement I think, because I it's more than just cleaning up a
warning. For me at least the warning pointed out that the expression
is not parsed would be expected (if this were a function and not a
macro), and it's just because of constraints on the inputs that
there's no functional change.

>> Signed-off-by: Corey Minyard <cminy...@mvista.com>
> Reviewed-by: Eric Blake <ebl...@redhat.com>
Reviewed-by: Ed Maste <ema...@freebsd.org>

Re: [Qemu-devel] [PATCH] ipmi: use parens to avoid unexpected macro var evaluation

[Ed Maste]

On 30 March 2017 at 12:12, Corey Minyard  wrote:
> This isn't quite right, a lot of these need parenthesis around the whole
> thing, and some of the macros are unused and need to be removed.
> I had submitted something for this a while ago, but it hadn't been
> taken.  I will re-submit.

Ok, thanks and apologies for not noticing existing patch and discussion.

On the topic of building with recent Clang there are also a large
number of warnings of the form "taking the address of a packed member
'magic' of class or structure 'QCowHeader' may result in an unaligned
pointer value [-Waddress-of-packed-member]". Unfortunately this
warning seems to be overly aggressive and prone to false positives.

[Qemu-devel] [PATCH] ipmi: use parens to avoid unexpected macro var evaluation

[Ed Maste]

Found via Clang warning: logical not is only applied to the left hand
side of this bitwise operator [-Wlogical-not-parentheses]

  !IPMI_BT_GET_HBUSY(ib->control_reg));
  ^~~~

expanded from macro 'IPMI_BT_SET_HBUSY'
   (((v & 1) << IPMI_BT_HBUSY_BIT)))
  ^ ~

Signed-off-by: Ed Maste <ema...@freebsd.org>
---
 hw/ipmi/isa_ipmi_bt.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c
index 1c69cb33f8..c1dea503a2 100644
--- a/hw/ipmi/isa_ipmi_bt.c
+++ b/hw/ipmi/isa_ipmi_bt.c
@@ -40,37 +40,37 @@
 #define IPMI_BT_CLR_WR_MASK(1 << IPMI_BT_CLR_WR_BIT)
 #define IPMI_BT_GET_CLR_WR(d)  (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1)
 #define IPMI_BT_SET_CLR_WR(d, v)   (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \
-   (((v & 1) << IPMI_BT_CLR_WR_BIT)))
+   v) & 1) << IPMI_BT_CLR_WR_BIT)))
 
 #define IPMI_BT_CLR_RD_MASK(1 << IPMI_BT_CLR_RD_BIT)
 #define IPMI_BT_GET_CLR_RD(d)  (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1)
 #define IPMI_BT_SET_CLR_RD(d, v)   (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \
-   (((v & 1) << IPMI_BT_CLR_RD_BIT)))
+   v) & 1) << IPMI_BT_CLR_RD_BIT)))
 
 #define IPMI_BT_H2B_ATN_MASK   (1 << IPMI_BT_H2B_ATN_BIT)
 #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1)
 #define IPMI_BT_SET_H2B_ATN(d, v)  (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \
-(((v & 1) << IPMI_BT_H2B_ATN_BIT)))
+v) & 1) << IPMI_BT_H2B_ATN_BIT)))
 
 #define IPMI_BT_B2H_ATN_MASK   (1 << IPMI_BT_B2H_ATN_BIT)
 #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1)
 #define IPMI_BT_SET_B2H_ATN(d, v)  (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \
-(((v & 1) << IPMI_BT_B2H_ATN_BIT)))
+v) & 1) << IPMI_BT_B2H_ATN_BIT)))
 
 #define IPMI_BT_SMS_ATN_MASK   (1 << IPMI_BT_SMS_ATN_BIT)
 #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1)
 #define IPMI_BT_SET_SMS_ATN(d, v)  (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \
-(((v & 1) << IPMI_BT_SMS_ATN_BIT)))
+v) & 1) << IPMI_BT_SMS_ATN_BIT)))
 
 #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT)
 #define IPMI_BT_GET_HBUSY(d)   (((d) >> IPMI_BT_HBUSY_BIT) & 0x1)
 #define IPMI_BT_SET_HBUSY(d, v)(d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \
-   (((v & 1) << IPMI_BT_HBUSY_BIT)))
+   v) & 1) << IPMI_BT_HBUSY_BIT)))
 
 #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT)
 #define IPMI_BT_GET_BBUSY(d)   (((d) >> IPMI_BT_BBUSY_BIT) & 0x1)
 #define IPMI_BT_SET_BBUSY(d, v)(d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \
-   (((v & 1) << IPMI_BT_BBUSY_BIT)))
+   v) & 1) << IPMI_BT_BBUSY_BIT)))
 
 
 /* Mask register */
@@ -80,12 +80,12 @@
 #define IPMI_BT_B2H_IRQ_EN_MASK  (1 << IPMI_BT_B2H_IRQ_EN_BIT)
 #define IPMI_BT_GET_B2H_IRQ_EN(d)(((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1)
 #define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | 
\
-(((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT)))
+v) & 1) << 
IPMI_BT_B2H_IRQ_EN_BIT)))
 
 #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT)
 #define IPMI_BT_GET_B2H_IRQ(d)   (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1)
 #define IPMI_BT_SET_B2H_IRQ(d, v)(d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \
-(((v & 1) << IPMI_BT_B2H_IRQ_BIT)))
+v) & 1) << IPMI_BT_B2H_IRQ_BIT)))
 
 typedef struct IPMIBT {
 IPMIBmc *bmc;
-- 
2.11.1

[Qemu-devel] [PATCH] Fix FreeBSD (10.x) build after 7dc9ae43

[Ed Maste]

Include sys/user.h for declaration of 'struct kinfo_proc'.
Add -lutil to qemu-ga link for kinfo_getproc.

Signed-off-by: Ed Maste <ema...@freebsd.org>
---
 configure  | 2 ++
 util/oslib-posix.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/configure b/configure
index 7d2a34e..5e66828 100755
--- a/configure
+++ b/configure
@@ -582,6 +582,8 @@ FreeBSD)
   audio_possible_drivers="oss sdl pa"
   # needed for kinfo_getvmmap(3) in libutil.h
   LIBS="-lutil $LIBS"
+  # needed for kinfo_getproc
+  libs_qga="-lutil $libs_qga"
   netmap=""  # enable netmap autodetect
   HOST_VARIANT_DIR="freebsd"
 ;;
diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index 67c6589..f631464 100644
--- a/util/oslib-posix.c
+++ b/util/oslib-posix.c
@@ -45,6 +45,7 @@
 
 #ifdef __FreeBSD__
 #include 
+#include 
 #include 
 #endif
 
-- 
2.8.1

[Qemu-devel] [PATCH] bsd-user: fix FreeBSD build after d148d90e

[Ed Maste]

Signed-off-by: Ed Maste <ema...@freebsd.org>
---
 bsd-user/main.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/bsd-user/main.c b/bsd-user/main.c
index d803d3e..d8367bd 100644
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -695,6 +695,16 @@ static void usage(void)
 
 THREAD CPUState *thread_cpu;
 
+bool qemu_cpu_is_self(CPUState *cpu)
+{
+return thread_cpu == cpu;
+}
+
+void qemu_cpu_kick(CPUState *cpu)
+{
+cpu_exit(cpu);
+}
+
 /* Assumes contents are already zeroed.  */
 void init_task_state(TaskState *ts)
 {
-- 
2.8.1

Re: [Qemu-devel] [PATCH] Fix bsd-user build after d915b7bb

[Ed Maste]

On 22 August 2016 at 12:20, Peter Maydell  wrote:
>
> Awkward that this missed rc4 by an hour or two :-(

Indeed, and I'm sorry that's the case. It wasn't even in the context
of the upcoming release that I tried building and stumbled across this
- I'm just back after some time away.

This is a good reminder of the need for us (FreeBSD) to get a build
bot going though.

[Qemu-devel] [PATCH] Fix bsd-user build after d915b7bb

[Ed Maste]

Must include "qemu-version.h" for the QEMU_PKGVERSION definition.

Signed-off-by: Ed Maste <ema...@freebsd.org>
---
 bsd-user/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsd-user/main.c b/bsd-user/main.c
index b4a0a00..0fb08e4 100644
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -17,6 +17,7 @@
  *  along with this program; if not, see <http://www.gnu.org/licenses/>.
  */
 #include "qemu/osdep.h"
+#include "qemu-version.h"
 #include 
 
 #include "qapi/error.h"
-- 
2.8.1

Re: [Qemu-devel] [PATCH 3/2] MAINTAINERS: Remove Blue Swirl leftovers

[Ed Maste]

On 29 June 2016 at 16:35, Ed Maste <ema...@freebsd.org> wrote:
>
> I agree with a large code drop being undesirable.

Here's a little more information for reference.

Sean's qemu-bsd-user branch is here: https://github.com/seanbruno/qemu-bsd-user
The last upstream merge was from commit d6550e9e about a month ago.

Diffstat reports:
 243 files changed, 34213 insertions(+), 2898 deletions(-)

225 of those files are in bsd-user or are bsd-user.mak files in default-configs.

The remaining changes outside of bsd-user are:
 Makefile.target |2
 configure   |   99 +
 hw/audio/sb16.c |6
 hw/dma/i8257.c  |8
 hw/intc/i8259.c |1
 hw/net/e1000.c  |2
 include/qemu/atomic.h   |4
 include/qemu/fprintf-fn.h   |   10
 net/clients.h   |5
 net/hub.c   |1
 net/net.c   |  224 ++
 net/tap-bsd.c   |1
 net/tap.c   |8
 qapi-schema.json|5
 qemu-char.c |7
 slirp/slirp_config.h|   18
 ui/x_keymap.c   |6

They seem to be mostly unrelated to bsd-user itself but are patches
taken from the FreeBSD ports tree - e.g. adding "-net pcap"
https://svnweb.freebsd.org/ports/head/emulators/qemu-devel/files/pcap-patch-net_net.c?revision=416075=markup

Re: [Qemu-devel] [PATCH 3/2] MAINTAINERS: Remove Blue Swirl leftovers

[Ed Maste]

On 29 June 2016 at 14:03, Peter Maydell  wrote:
>
> I think from an upstream-maintainer viewpoint the question is
> whether a code drop would be just a code drop, or whether
> it gets us to a position where we have an active upstream
> maintainer for the bsd-user code. I think the latter would
> be a win for everybody.

I can't speak for Sean and he's AFK for a week or two, but he's been
performing this function for the fork for some time -- updating it for
changes in the rest of QEMU, etc. I think we've been stuck on
upstreaming it because it is somewhat awkward to refactor and is a
reasonable amount of effort, and we've lacked a bsd-user maintainer to
review or approve the patches anyhow.

I agree with a large code drop being undesirable. Given current
expectations (with bsd-user unmaintained) I hope we can make another
push to refactor and upstream the changes. We should be able to put in
some effort to present the patches in a sensible and logical order and
I'm willing to help with that. Perhaps we'll need a little leeway on
the parts specific to bsd-user, but I'm really hopeful we can make
this happen.

I also hope some folks from NetBSD, OpenBSD, DragonflyBSD and others
will help test the patch sets.

Re: [Qemu-devel] [PATCH 3/2] MAINTAINERS: Remove Blue Swirl leftovers

[Ed Maste]

On 20 June 2016 at 10:19, Markus Armbruster  wrote:
>
> As per Paolo's recommendation, downgrade status of "BSD user" from
> Maintained to Orphan since the FreeBSD guys effectively forked it, and
> "SPARC target" from Maintained to Odd Fixes, since we still have the
> overall TCG maintainer looking after it.

Note that we are still very interested in having the BSD user
refactoring and improvements upstream, and are not interested in
indefinitely carrying around a fork. We do need to figure out how to
effectively restart the effort to upstream the work.

The bsd-user work is stable and usable. We use it to cross-build more
than 20,000 packages of third-party software in the FreeBSD ports
collection.

Re: [Qemu-devel] [PATCH v3 00/20] GICv3 emulation

[Ed Maste]

On 23 June 2016 at 07:36, Laszlo Ersek <ler...@redhat.com> wrote:
> On 06/22/16 22:53, Peter Maydell wrote:
>> On 22 June 2016 at 19:09, Ed Maste <ema...@freebsd.org> wrote:
>>> On 15 June 2016 at 06:10, Peter Maydell <peter.mayd...@linaro.org> wrote:
>>>>
>>>> A quick scan through http://fxr.watson.org/fxr/source/arm64/arm64/gic_v3.c
>>>> doesn't seem to show it setting the IGROUPR registers anywhere,
>>>> so it probably is a guest bug. (You can use "-d 'trace:gicv3*'" to
>>>> enable the tracepoints for the GIC which would let you check whether
>>>> the guest ever tries to write to the group config registers.)
>>>
>>> Is there a prebuilt QEMU_EFI.fd available somewhere for testing a
>>> FreeBSD change to address this? I've been using the prebuilt ones from
>>> https://wiki.linaro.org/LEG/UEFIforQEMU and the latest one I had did
>>> not start with gic-version=3.
>>
>> Yeah, it looks like the same bug is also present in UEFI itself
>> (it's super popular!). Laszlo, Ard, do you have a prebuilt
>> UEFI binary with Ard's fix?
>
> I just put up one here, in case it's still needed:
>
> http://people.redhat.com/~lersek/82a5e88f-f1e1-42e2-8462-66974c9cbfff/

Thank you. I ran your QEMU_EFI.fd with gic_version=3 and UEFI and
FreeBSD start up successfully (as expected, based on the discussion in
this thread).

It sounds like we'll need to build a hacked UEFI build as Peter
Maydell suggested in order to actually test a FreeBSD fix when we have
it.

-Ed

Re: [Qemu-devel] [PATCH v3 00/20] GICv3 emulation

[Ed Maste]

On 22 June 2016 at 16:53, Peter Maydell  wrote:
>
> Yeah, it looks like the same bug is also present in UEFI itself
> (it's super popular!). Laszlo, Ard, do you have a prebuilt
> UEFI binary with Ard's fix?
>
> Probably you'll find that if UEFI is configuring the GIC interrupt
> groups FreeBSD will boot even without doing it itself, but I
> think ideally FreeBSD shouldn't assume the bootloader's done
> that job for it.

Oh, good point. Indeed FreeBSD should not make this assumption. I'm
not sure how I'd test the FreeBSD fix then though (booting w/o the
UEFI firmware doing this configuration).

Re: [Qemu-devel] [PATCH v3 00/20] GICv3 emulation

[Ed Maste]

On 15 June 2016 at 06:10, Peter Maydell  wrote:
>
> A quick scan through http://fxr.watson.org/fxr/source/arm64/arm64/gic_v3.c
> doesn't seem to show it setting the IGROUPR registers anywhere,
> so it probably is a guest bug. (You can use "-d 'trace:gicv3*'" to
> enable the tracepoints for the GIC which would let you check whether
> the guest ever tries to write to the group config registers.)

Is there a prebuilt QEMU_EFI.fd available somewhere for testing a
FreeBSD change to address this? I've been using the prebuilt ones from
https://wiki.linaro.org/LEG/UEFIforQEMU and the latest one I had did
not start with gic-version=3.

Re: [Qemu-devel] [PATCH] bsd-user: Suppress gcc 4.x -Wpointer-sign (included in -Wall) warning

[Ed Maste]

On 5 April 2016 at 10:54, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 5 April 2016 at 15:46, Ed Maste <ema...@freebsd.org> wrote:
>> This is the same change as b55266b5 in linux-user.
>>
>> Signed-off-by: Ed Maste <ema...@freebsd.org>
>
> Do you have many more of these bsd related patches to come?
> It might be easier to deal with them all in one patchseries...

I have nothing beyond these two. I caught the missing #include from a
build warning, but unfortunately didn't notice this (const char *)
difference vs linux-user when I mailed the first patch.

There are some warnings remaining in bsd-user still, but these should
be investigated after we sort out the bsd-user rework from Stacy Son
and Sean Bruno. I don't expect to have any further work until then.

[Qemu-devel] [PATCH] bsd-user: Suppress gcc 4.x -Wpointer-sign (included in -Wall) warning

[Ed Maste]

This is the same change as b55266b5 in linux-user.

Signed-off-by: Ed Maste <ema...@freebsd.org>
---
 bsd-user/uaccess.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsd-user/uaccess.c b/bsd-user/uaccess.c
index b7b3a06..91e2067 100644
--- a/bsd-user/uaccess.c
+++ b/bsd-user/uaccess.c
@@ -51,7 +51,7 @@ abi_long target_strlen(abi_ulong guest_addr1)
 ptr = lock_user(VERIFY_READ, guest_addr, max_len, 1);
 if (!ptr)
 return -TARGET_EFAULT;
-len = qemu_strnlen((char *)ptr, max_len);
+len = qemu_strnlen((const char *)ptr, max_len);
 unlock_user(ptr, guest_addr, 0);
 guest_addr += len;
 /* we don't allow wrapping or integer overflow */
-- 
2.4.6

[Qemu-devel] [PATCH] bsd-user: add qemu/cutils.h include after f348b6d

[Ed Maste]

Signed-off-by: Ed Maste <ema...@freebsd.org>
---
 bsd-user/uaccess.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsd-user/uaccess.c b/bsd-user/uaccess.c
index 7cb6d17..b7b3a06 100644
--- a/bsd-user/uaccess.c
+++ b/bsd-user/uaccess.c
@@ -1,5 +1,6 @@
 /* User memory access */
 #include "qemu/osdep.h"
+#include "qemu/cutils.h"
 
 #include "qemu.h"
 
-- 
2.4.6

Re: [Qemu-devel] [PATCH v2] util: retry getaddrinfo if getting EAI_BADFLAGS with AI_V4MAPPED

[Ed Maste]

On 4 April 2016 at 16:22, Daniel P. Berrange <berra...@redhat.com> wrote:
> The FreeBSD header files define the AI_V4MAPPED but its
> implementation of getaddrinfo() always returns an error
> when that flag is set. eg
> [...]
> ---
>
> Changed in v2:
>
>  - Fix test case usage of AI_V4MAPPED
>  - Don't disable AI_V4MAPPED at build time, detect it
>at runtime, so we catch any platform with broken impl

This fixes the remaining two of three failures I reported earlier
today in 'gmake check' on FreeBSD.

Tested-by: Ed Maste <ema...@freebsd.org>

Re: [Qemu-devel] [PATCH] crypto: fix nettle config check for running pbkdf test

[Ed Maste]

On 4 April 2016 at 20:01, Bruce Rogers <brog...@suse.com> wrote:
>>>> On 4/4/2016 at 09:24 AM, "Daniel P. Berrange" <berra...@redhat.com> wrote:
>> The pbkdf test is being built based on a check for CONFIG_NETTLE.
>> As of fff2f982ab6ac0dd2b641d30303f72270a019f28, it should be
>> instead checking CONFIG_NETTLE_KDF
>>
>> Reported-by: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
>> Reported-by: Bruce Rogers <brog...@suse.com>
>> Signed-off-by: Daniel P. Berrange <berra...@redhat.com>
>> ---
>>  tests/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/Makefile b/tests/Makefile
>> index 45b9048..651d8b2 100644
>> --- a/tests/Makefile
>> +++ b/tests/Makefile
>> @@ -92,7 +92,7 @@ check-unit-$(CONFIG_GNUTLS) +=
>> tests/test-io-channel-tls$(EXESUF)
>>  check-unit-y += tests/test-io-channel-command$(EXESUF)
>>  check-unit-y += tests/test-io-channel-buffer$(EXESUF)
>>  check-unit-y += tests/test-base64$(EXESUF)
>> -check-unit-$(if $(CONFIG_NETTLE),y,$(CONFIG_GCRYPT_KDF)) +=
>> tests/test-crypto-pbkdf$(EXESUF)
>> +check-unit-$(if $(CONFIG_NETTLE_KDF),y,$(CONFIG_GCRYPT_KDF)) +=
>> tests/test-crypto-pbkdf$(EXESUF)
>>  check-unit-y += tests/test-crypto-ivgen$(EXESUF)
>>  check-unit-y += tests/test-crypto-afsplit$(EXESUF)
>>  check-unit-y += tests/test-crypto-xts$(EXESUF)
>
> This is the same patch I've been running with - which has worked fine for me.
> Thanks!
>
> Bruce
>
> Tested-by: Bruce Rogers <brog...@suse.com>

This fixes one of the three FreeBSD test failures I reported earlier
in the thread "[PATCH v2 0/2] Fix for compile on FreeBSD/i386 (and
others?)".

Tested-by: Ed Maste <ema...@freebsd.org>

Re: [Qemu-devel] [PATCH v2 0/2] Fix for compile on FreeBSD/i386 (and others?)

[Ed Maste]

On 4 April 2016 at 10:35, Alex Bennée  wrote:
> Only the first patch has actually changed. Instead of moving the read
> inside the write seqlock it is now done using the seqlock_read_*
> primitives.
>
> Build tested on a FreeBSB/i386 VM with these applied:
>
>   https://github.com/berrange/qemu/tree/freebsd-fixes
>
> There are still a ton of unrelated warnings being kicked out of the compiler
> though. On the VM "make check" fails at ... but as the build was

I'm not sure what the "..." is supposed to be, but FWIW I tried the
test suite just now and have 3 tests failing on FreeBSD 10.3-STABLE on
amd64. I've commented them out locally as a temporary workaround.

The tests (and failures) are:

* tests/test-io-channel-socket

GTESTER tests/test-io-channel-socket
/tank/emaste/src/qemu/tests/Makefile:650: recipe for target
'check-tests/test-io-channel-socket' failed

* tests/test-crypto-pbkdf

Unexpected error in qcrypto_pbkdf2() at crypto/pbkdf-stub.c:41:
No crypto library supporting PBKDF in this build: Function not implemented
(and many simliar)

* tests/ipmi-bt-test

qemu-system-i386: Unable to connect character device ipmi0: address
resolution failed for localhost:40135: Invalid value for ai_flags
**
ERROR:tests/ipmi-bt-test.c:320:test_connect: assertion failed: (rv == 1)
(and three similar errors)

[Qemu-devel] [PATCH] bsd-user: add necessary includes to fix warnings

[Ed Maste]

Signed-off-by: Ed Maste <ema...@freebsd.org>
---
 bsd-user/syscall.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/bsd-user/syscall.c b/bsd-user/syscall.c
index 35f784c..47cf865 100644
--- a/bsd-user/syscall.c
+++ b/bsd-user/syscall.c
@@ -17,6 +17,8 @@
  *  along with this program; if not, see <http://www.gnu.org/licenses/>.
  */
 #include "qemu/osdep.h"
+#include "qemu/cutils.h"
+#include "qemu/path.h"
 #include 
 #include 
 #include 
-- 
2.4.6

Re: [Qemu-devel] [PATCH] io: fix build on FreeBSD

[Ed Maste]

On 25 February 2016 at 11:41, Daniel P. Berrange  wrote:
> On Thu, Feb 25, 2016 at 09:37:18AM -0700, Eric Blake wrote:
>>
>> Oh, right. That's annoying.  What about:
>>
>> #ifndef EAI_ADDRFAMILY
>> #define EAI_ADDRFAMILY 0
>> #endif
>>
>> if ((EAI_ADDRFAMILY && gaierr == EAIADDRFAMILY) ||
>> gaierr == EAI_FAMILY...
>>
>> to shut up gcc 6, while still hoisting the preprocessor logic outside of
>> the expression?
>
> To be honest, I think the preprocessor check inside the expression isn't
> a big deal and clearer than playing games like this.

I wasn't a fan of putting the preprocessor check inside the expression
either, but no clear and concise alternative came to mind.  I think
it's easier to see both intent and effect with the preoprocessor check
than with the above.

[Qemu-devel] [PATCH] io: fix build on FreeBSD

[Ed Maste]

EAI_ADDRFAMILY is obsolete and FreeBSD/s netdb.h does not provide a
definition.

Signed-off-by: Ed Maste <ema...@freebsd.org>
---
 tests/test-io-channel-socket.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/test-io-channel-socket.c b/tests/test-io-channel-socket.c
index 0697363..f4dbd60 100644
--- a/tests/test-io-channel-socket.c
+++ b/tests/test-io-channel-socket.c
@@ -63,7 +63,10 @@ static int check_protocol_support(bool *has_ipv4, bool 
*has_ipv6)
 
 gaierr = getaddrinfo("::1", NULL, , );
 if (gaierr != 0) {
-if (gaierr == EAI_ADDRFAMILY ||
+if (
+#ifdef EAI_ADDRFAMILY
+gaierr == EAI_ADDRFAMILY ||
+#endif
 gaierr == EAI_FAMILY ||
 gaierr == EAI_NONAME) {
 *has_ipv6 = false;
-- 
2.4.6

[Qemu-devel] [PATCH] tap-bsd: use user-specified tap device if it already exists

[Ed Maste]

---
As an aside this was reviewed on FreeBSD's Phabricator here:
https://reviews.freebsd.org/D3969

 net/tap-bsd.c | 38 +-
 1 file changed, 33 insertions(+), 5 deletions(-)

diff --git a/net/tap-bsd.c b/net/tap-bsd.c
index 7028d9b..0103a97 100644
--- a/net/tap-bsd.c
+++ b/net/tap-bsd.c
@@ -109,8 +109,7 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
 
 #define PATH_NET_TAP "/dev/tap"
 
-int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
- int vnet_hdr_required, int mq_required, Error **errp)
+static int tap_open_clone(char *ifname, int ifname_size, Error **errp)
 {
 int fd, s, ret;
 struct ifreq ifr;
@@ -126,7 +125,8 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
 ret = ioctl(fd, TAPGIFNAME, (void *));
 if (ret < 0) {
 error_setg_errno(errp, errno, "could not get tap interface name");
-goto error;
+close(fd);
+return -1;
 }
 
 if (ifname[0] != '\0') {
@@ -135,19 +135,47 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
 if (s < 0) {
 error_setg_errno(errp, errno,
  "could not open socket to set interface name");
-goto error;
+close(fd);
+return -1;
 }
 ifr.ifr_data = ifname;
 ret = ioctl(s, SIOCSIFNAME, (void *));
 close(s);
 if (ret < 0) {
 error_setg(errp, "could not set tap interface name");
-goto error;
+close(fd);
+return -1;
 }
 } else {
 pstrcpy(ifname, ifname_size, ifr.ifr_name);
 }
 
+return fd;
+}
+
+int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
+ int vnet_hdr_required, int mq_required, Error **errp)
+{
+int fd = -1;
+
+/* If the specified tap device already exists just use it. */
+if (ifname[0] != '\0') {
+char dname[100];
+snprintf(dname, sizeof dname, "/dev/%s", ifname);
+TFR(fd = open(dname, O_RDWR));
+if (fd < 0 && errno != ENOENT) {
+error_setg_errno(errp, errno, "could not open %s", dname);
+return -1;
+}
+}
+
+if (fd < 0) {
+/* Tap device not specified or does not exist. */
+if ((fd = tap_open_clone(ifname, ifname_size, errp)) < 0) {
+return -1;
+}
+}
+
 if (*vnet_hdr) {
 /* BSD doesn't have IFF_VNET_HDR */
 *vnet_hdr = 0;
-- 
2.4.6

[Qemu-devel] [PATCH] tap-bsd: use user-specified tap device if it already exists

[Ed Maste]

Acked-by: Roger Pau Monné <roger@citrix.com>
Signed-off-by: Ed Maste <ema...@freebsd.org>
---
As an aside this was reviewed on FreeBSD's Phabricator here:
https://reviews.freebsd.org/D3969

Resend with Signed-off-by.

 net/tap-bsd.c | 38 +-
 1 file changed, 33 insertions(+), 5 deletions(-)

diff --git a/net/tap-bsd.c b/net/tap-bsd.c
index 7028d9b..0103a97 100644
--- a/net/tap-bsd.c
+++ b/net/tap-bsd.c
@@ -109,8 +109,7 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
 
 #define PATH_NET_TAP "/dev/tap"
 
-int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
- int vnet_hdr_required, int mq_required, Error **errp)
+static int tap_open_clone(char *ifname, int ifname_size, Error **errp)
 {
 int fd, s, ret;
 struct ifreq ifr;
@@ -126,7 +125,8 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
 ret = ioctl(fd, TAPGIFNAME, (void *));
 if (ret < 0) {
 error_setg_errno(errp, errno, "could not get tap interface name");
-goto error;
+close(fd);
+return -1;
 }
 
 if (ifname[0] != '\0') {
@@ -135,19 +135,47 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
 if (s < 0) {
 error_setg_errno(errp, errno,
  "could not open socket to set interface name");
-goto error;
+close(fd);
+return -1;
 }
 ifr.ifr_data = ifname;
 ret = ioctl(s, SIOCSIFNAME, (void *));
 close(s);
 if (ret < 0) {
 error_setg(errp, "could not set tap interface name");
-goto error;
+close(fd);
+return -1;
 }
 } else {
 pstrcpy(ifname, ifname_size, ifr.ifr_name);
 }
 
+return fd;
+}
+
+int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
+ int vnet_hdr_required, int mq_required, Error **errp)
+{
+int fd = -1;
+
+/* If the specified tap device already exists just use it. */
+if (ifname[0] != '\0') {
+char dname[100];
+snprintf(dname, sizeof dname, "/dev/%s", ifname);
+TFR(fd = open(dname, O_RDWR));
+if (fd < 0 && errno != ENOENT) {
+error_setg_errno(errp, errno, "could not open %s", dname);
+return -1;
+}
+}
+
+if (fd < 0) {
+/* Tap device not specified or does not exist. */
+if ((fd = tap_open_clone(ifname, ifname_size, errp)) < 0) {
+return -1;
+}
+}
+
 if (*vnet_hdr) {
 /* BSD doesn't have IFF_VNET_HDR */
 *vnet_hdr = 0;
-- 
2.4.6

Re: [Qemu-devel] [PATCH] qtest: Add assertion that required environment variable is set

[Ed Maste]

On 1 April 2015 at 18:45, Peter Maydell peter.mayd...@linaro.org wrote:
 On 1 April 2015 at 22:14, Paolo Bonzini pbonz...@redhat.com wrote:
 On 01/04/2015 23:06, John Snow wrote:

 if (qemu == NULL) {
   fprintf(stderr, ...);
   g_assert_not_reached();
 }

 Though that does read a little strangely. (Here's a nice error message
 for something we are asserting will never happen.)

 Just exit(1); then.  :)

 Good idea, this is annoying.

 Also irritating is the way it silently requires
 the binary to have a name in the shape it was
 expecting, which can catch you out if you were
 trying to set it to a wrapper shell script that
 invokes valgrind or something...

I don't really have enough context to propose a good user-facing
message with a tip for manually executing this, so hopefully someone
else can provide one. I just noticed one other instance that already
had an assertion on getenv(QTEST_QEMU_BINARY) being non-null.

-Ed

[Qemu-devel] [PATCH] Use $(MAKE) for recursive make

[Ed Maste]

On BSDs make is typically BSD make, while gmake is GNU make.

Signed-off-by: Ed Maste ema...@freebsd.org
---
 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 88bce56..ee40397 100644
--- a/Makefile
+++ b/Makefile
@@ -331,8 +331,8 @@ distclean: clean
rm -rf $$d || exit 1 ; \
 done
rm -Rf .sdk
-   if test -f pixman/config.log; then make -C pixman distclean; fi
-   if test -f dtc/version_gen.h; then make $(DTC_MAKE_ARGS) clean; fi
+   if test -f pixman/config.log; then $(MAKE) -C pixman distclean; fi
+   if test -f dtc/version_gen.h; then $(MAKE) $(DTC_MAKE_ARGS) clean; fi
 
 KEYMAPS=da en-gb  et  fr fr-ch  is  lt  modifiers  no  pt-br  sv \
 ar  de en-us  fi  fr-be  hr it  lv  nl pl  ru th \
-- 
2.2.2

[Qemu-devel] [PATCH] qtest: Add assertion that required environment variable is set

[Ed Maste]

Signed-off-by: Ed Maste ema...@freebsd.org
---
 tests/libqtest.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/libqtest.c b/tests/libqtest.c
index 12d65bd..54550a8 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -453,6 +453,7 @@ void qtest_qmp_discard_response(QTestState *s, const char 
*fmt, ...)
 const char *qtest_get_arch(void)
 {
 const char *qemu = getenv(QTEST_QEMU_BINARY);
+g_assert(qemu != NULL);
 const char *end = strrchr(qemu, '/');
 
 return end + strlen(/qemu-system-);
-- 
2.2.2

Re: [Qemu-devel] [PATCH 4/4] ahci-test: improve rw buffer patterns

[Ed Maste]

On 23 March 2015 at 12:56, John Snow js...@redhat.com wrote:
 My pattern was cyclical every 256 bytes, so it missed a fairly obvious
 failure case. Add some rand() pepper into the test pattern, and for large
 patterns that exceed 256 sectors, start writing an ID per-sector so that
 we never generate identical sector patterns.

 Signed-off-by: John Snow js...@redhat.com
 Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
 Tested-by: Andreas Färber afaer...@suse.de
 Message-id: 1426811056-2202-5-git-send-email-js...@redhat.com
 ---
  tests/ahci-test.c | 36 
  1 file changed, 28 insertions(+), 8 deletions(-)

As of the introduction of this test the test suite fails on FreeBSD,
with 6 errors of the form:

ERROR:tests/ahci-test.c:790:ahci_test_io_rw_simple: assertion failed
(memcmp(tx, rx, bufsize) == 0): (0x == 0x)
GTester: last random seed: R02S76f68c4cfb2d54af66de227ed44fd54a

I haven't yet done any investigation beyond bisecting.

Re: [Qemu-devel] [PATCH 4/4] ahci-test: improve rw buffer patterns

[Ed Maste]

On 31 March 2015 at 16:58, John Snow js...@redhat.com wrote:

 which test case does it fail under? io_rw_simple is shared by a number of
 different tests.

I'm not sure off hand how to run an individual test to confirm, but
the testrun output up to the failure is:

  LINK  tests/spapr-phb-test
GTESTER check-qtest-aarch64
GTESTER check-qtest-alpha
GTESTER check-qtest-arm
GTESTER check-qtest-cris
GTESTER check-qtest-i386
blkdebug: Suspended request 'A'
blkdebug: Resuming request 'A'
**
ERROR:tests/ahci-test.c:790:ahci_test_io_rw_simple: assertion failed
(memcmp(tx, rx, bufsize) == 0): (0x == 0x)
GTester: last random seed: R02S181acd6574060796874e02dbdeb86199

Generally speaking I've only encountered build errors on FreeBSD, and
as long as it built the full test suite passed.

 I suspect deeply that this test pattern has just unearthed an existing
 problem.

Yeah, it's almost certainly just exposing the existing failure.

Re: [Qemu-devel] [PATCH 4/4] ahci-test: improve rw buffer patterns

[Ed Maste]

On 31 March 2015 at 17:44, John Snow js...@redhat.com wrote:

 My apologies;

Not at all, thanks for your help!

 Head into your build directory and try this:

 make tests/ahci-test
 export QTEST_QEMU_BINARY=i386-softmmu/qemu-system-i386
 export QTEST_QEMU_IMG=./qemu-img
 ./tests/ahci-test

 This should show you which test in particular is failing. I have a hunch it
 will be the PIO, again...

Correct:

feynman% ./tests/ahci-test
/i386/ahci/sanity: OK
/i386/ahci/pci_spec: OK
/i386/ahci/pci_enable: OK
/i386/ahci/hba_spec: OK
/i386/ahci/hba_enable: OK
/i386/ahci/identify: OK
/i386/ahci/io/pio/lba28/simple: **
ERROR:tests/ahci-test.c:790:ahci_test_io_rw_simple: assertion failed
(memcmp(tx, rx, bufsize) == 0): (0x == 0x)
zsh: abort (core dumped)  ./tests/ahci-test

 In the meantime, what is your setup? which release, what architecture?

This is the FreeBSD stable/10 branch on amd64 (so part way between
10.1 and what will become 10.2):

FreeBSD feynman 10.1-STABLE FreeBSD 10.1-STABLE #28
r280427+86df2de(stable-10): Thu Mar 26 16:07:47 EDT 2015
emaste@feynman:/tank/emaste/obj/tank/emaste/src/git-stable-10/sys/GENERIC
 amd64

Re: [Qemu-devel] [PATCH 4/4] ahci-test: improve rw buffer patterns

[Ed Maste]

On 31 March 2015 at 17:55, Ed Maste ema...@freebsd.org wrote:

 feynman% ./tests/ahci-test
 /i386/ahci/sanity: OK
 /i386/ahci/pci_spec: OK
 /i386/ahci/pci_enable: OK
 /i386/ahci/hba_spec: OK
 /i386/ahci/hba_enable: OK
 /i386/ahci/identify: OK
 /i386/ahci/io/pio/lba28/simple: **
 ERROR:tests/ahci-test.c:790:ahci_test_io_rw_simple: assertion failed
 (memcmp(tx, rx, bufsize) == 0): (0x == 0x)
 zsh: abort (core dumped)  ./tests/ahci-test

Well, that's rather strange: I had to head out after your last
follow-up, and then when picking this up again from home I ended up
accidentally breaking my build directory and then did a fresh clean
build. Now I can't reproduce the error. Running tests/ahci-test
reports all OK.

So I'm not quite sure what was wrong, but it looks like this is not a
real issue -- sorry for the noise.

Re: [Qemu-devel] [PATCH] vscclient: Add required headers to fix build on FreeBSD

[Ed Maste]

On 18 June 2014 11:22, Andreas Färber afaer...@suse.de wrote:
 Am 18.06.2014 16:41, schrieb Paolo Bonzini:
 Il 18/06/2014 14:58, Ed Maste ha scritto:
 Signed-off-by: Ed Maste ema...@freebsd.org
 ---
  libcacard/vscclient.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/libcacard/vscclient.c b/libcacard/vscclient.c
 index ab9b2b8..80111df 100644
 --- a/libcacard/vscclient.c
 +++ b/libcacard/vscclient.c
 @@ -11,6 +11,8 @@
   */

  #ifndef _WIN32
 +#include sys/socket.h
 +#include netinet/in.h
  #include netdb.h
  #define closesocket(x) close(x)
  #endif


 Reviewed-by: Paolo Bonzini pbonz...@redhat.com

 Looks okay, CC'ing Alon and -trivial.

Ping - can we bring in this build fix other than by waiting on -trivial?

[Qemu-devel] [PATCH] vscclient: Add required headers to fix build on FreeBSD

[Ed Maste]

Signed-off-by: Ed Maste ema...@freebsd.org
---
 libcacard/vscclient.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libcacard/vscclient.c b/libcacard/vscclient.c
index ab9b2b8..80111df 100644
--- a/libcacard/vscclient.c
+++ b/libcacard/vscclient.c
@@ -11,6 +11,8 @@
  */
 
 #ifndef _WIN32
+#include sys/socket.h
+#include netinet/in.h
 #include netdb.h
 #define closesocket(x) close(x)
 #endif
-- 
1.8.4

Re: [Qemu-devel] [PATCH] vscclient: Restore sockets.h include to fix build on FreeBBSD

[Ed Maste]

On 17 June 2014 15:23, Ed Maste ema...@freebsd.org wrote:
 Commit 2a0c46d (vscclient: use glib thread primitives not qemu)
 removed #include qemu/sockets.h, required for socket-related function
 declarations and constants.

Disregard this patch; a replacement has been sent to add the two
required headers.

Re: [Qemu-devel] [PULL 2/8] vscclient: use glib thread primitives not qemu

[Ed Maste]

On 10 June 2014 01:56, Paolo Bonzini pbonz...@redhat.com wrote:
 From: Michael Tokarev m...@tls.msk.ru

 Use glib-provided thread primitives in vscclient instead of
 qemu ones, and do not use qemu sockets in there (open-code
 call to WSAStartup() for windows to initialize things).

 This way, vscclient becomes more stand-alone, independent on
 qemu internals.

 Signed-off-by: Michael Tokarev m...@tls.msk.ru
 Reviewed-by: Alon Levy al...@redhat.com
 Tested-by: Alon Levy al...@redhat.com
 Signed-off-by: Paolo Bonzini pbonz...@redhat.com
 ---
  libcacard/vscclient.c | 70 
 +++
  1 file changed, 37 insertions(+), 33 deletions(-)

 diff --git a/libcacard/vscclient.c b/libcacard/vscclient.c
 index 6693900..ab9b2b8 100644
 --- a/libcacard/vscclient.c
 +++ b/libcacard/vscclient.c
 @@ -12,12 +12,10 @@

  #ifndef _WIN32
  #include netdb.h
 +#define closesocket(x) close(x)
  #endif
 -#include glib.h

  #include qemu-common.h
 -#include qemu/thread.h
 -#include qemu/sockets.h

This change breaks the build on FreeBSD:

libcacard/vscclient.c: In function 'send_msg':
libcacard/vscclient.c:111: warning: implicit declaration of function 'htonl'
libcacard/vscclient.c:111: warning: nested extern declaration of 'htonl'
libcacard/vscclient.c: In function 'on_host_init':
libcacard/vscclient.c:248: warning: implicit declaration of function 'ntohl'
libcacard/vscclient.c:248: warning: nested extern declaration of 'ntohl'
libcacard/vscclient.c: In function 'connect_to_qemu':
libcacard/vscclient.c:601: warning: implicit declaration of function 'socket'
libcacard/vscclient.c:601: warning: nested extern declaration of 'socket'
...

Re: [Qemu-devel] [PULL 2/8] vscclient: use glib thread primitives not qemu

[Ed Maste]

On 17 June 2014 13:15, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 17/06/2014 19:10, Ed Maste ha scritto:

 This change breaks the build on FreeBSD:

 libcacard/vscclient.c: In function 'send_msg':
 libcacard/vscclient.c:111: warning: implicit declaration of function
 'htonl'
 ...

 Can you prepare a patch yourself?  I would be guessing the right header to
 include, sorry.

I can get it to build by either restoring the #include of
qemu/sockets.h, or explicitly #including sys/socket.h and
netinet/in.h.  I'm happy to send a signed-off patch for either change,
but it seems there must be more to the original change that I'm
missing.  What provides the declarations for socket(), htonl(),
AF_INET etc. in the Linux build?

[Qemu-devel] [PATCH] vscclient: Restore sockets.h include to fix build on FreeBBSD

[Ed Maste]

Commit 2a0c46d (vscclient: use glib thread primitives not qemu)
removed #include qemu/sockets.h, required for socket-related function
declarations and constants.

Signed-off-by: Ed Maste ema...@freebsd.org
---
 libcacard/vscclient.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libcacard/vscclient.c b/libcacard/vscclient.c
index ab9b2b8..aa25061 100644
--- a/libcacard/vscclient.c
+++ b/libcacard/vscclient.c
@@ -12,10 +12,10 @@
 
 #ifndef _WIN32
 #include netdb.h
-#define closesocket(x) close(x)
 #endif
 
 #include qemu-common.h
+#include qemu/sockets.h
 
 #include vscard_common.h
 
-- 
1.9.0

Re: [Qemu-devel] [PATCH] bsd-user/mmap.c: Don't try to override g_malloc/g_free

[Ed Maste]

On 3 June 2014 19:51, Peter Maydell peter.mayd...@linaro.org wrote:
 Trying to override the implementations of g_malloc and g_free is
 a really bad idea -- it means statically linked builds fail to
 link (because of the multiple definitions provided by this file
 and by glib), and non-statically linked builds segfault as soon
 as they try to do anything more complicated than printing the
 usage message. Remove these overridden versions and just use
 the glib ones.

 This is sufficient that bsd-user can run basic x86-64
 binaries on OpenBSD again; FreeBSD and NetBSD seem to have
 further issues.

 Signed-off-by: Peter Maydell peter.mayd...@linaro.org

Reviewed-by: Ed Maste ema...@freebsd.org

Re: [Qemu-devel] [Qemu-trivial] [PATCH] configure: Put tempfiles in subdir so we can clean up libtool files

[Ed Maste]

On 6 May 2014 10:36, Eric Blake ebl...@redhat.com wrote:

 mktemp is not POSIX.  BSD mktemp lacks -t:

 http://www.freebsd.org/cgi/man.cgi?query=mktempapropos=0sektion=1manpath=Red+Hat+Linux%2Fi386+9format=html

You managed to link to a mktemp man page for some old Red Hat version
there (note the URL); FreeBSD's mktemp man page (for the 9.2 release)
is here:

http://www.freebsd.org/cgi/man.cgi?query=mktempapropos=0sektion=1manpath=FreeBSD+9.2-RELEASEarch=defaultformat=html

which supports -t, but with a different meaning compared to contemporary Linux.

Re: [Qemu-devel] [PATCH] qemu-thread-posix: Fix build against older glibc version

[Ed Maste]

On 11 March 2014 12:13, Dr. David Alan Gilbert dgilb...@redhat.com wrote:

 Except pthread_setname_np is not portable and was previously
 ifdef'd _GNU_SOURCE anyway, and the parameters on other OSs
 maybe different (freebsd has got a 3rd parameter for no
 apparent reason).

No, glibc's arguments are identical to FreeBSD's.  The difference is
that it's pthread_set_name_np (with an extra underscore).

FreeBSD: void pthread_set_name_np(pthread_t, const char *);
glibc: int pthread_setname_np(pthread_t, const char *);
NetBSD: int pthread_setname_np(pthread_t, const char *, void *);
Darwin: pthread_setname_np(const char *);

Re: [Qemu-devel] [RFC for-2.0] bswap: Fix build on FreeBSD 10.0

[Ed Maste]

On 2 April 2014 14:52, Richard Henderson r...@twiddle.net wrote:
 On 04/02/2014 07:06 AM, Andreas Färber wrote:
 FreeBSD 10.0-RELEASE has bswap16() etc. macros defined in sys/endian.h,
 which leads to a conflict with our static inline definitions.

 Force using the system version of the macros.

 Signed-off-by: Andreas Färber andreas.faer...@web.de
 ---
  On 9.0-RELEASE I did not have this issue, so unsure if some version check
  is needed or some more generic configure check?

 Looks plausible, but I have no bsd specific experience.
 I'd say if it works for both 9.0 and 10.0, let it go in as is.

This change builds fine for me on FreeBSD 9.

-Ed

Re: [Qemu-devel] [PATCH v3 01/19] bsd-user: refresh freebsd system call numbers

[Ed Maste]

On 27 January 2014 14:30, Peter Maydell peter.mayd...@linaro.org wrote:

 though this patch would look much nicer if you hadn't
 changed every single line in the file including the
 ones for syscalls we already had the #defines for.

The new version of this file was generated from the canonical FreeBSD
syscall numbering, using the same script that's in the FreeBSD tree
(makesyscalls.sh).  Future updates shouldn't encounter this again.

-Ed

[Qemu-devel] Request for volunteer to commit bsd-user patch set

[Ed Maste]

On 13 December 2013 07:44, Paolo Bonzini pbonz...@redhat.com wrote:

 Post the patches.  I'll review the non-bsd-user parts again.  And then
 the next step is to find someone who commits them...  shouldn't be hard
 since you probably know much more about this code than anyone else.

Is someone willing to shepherd the bsd-user patches in?  I hope this
can happen soon so that we can get broader testing during the 1.8
release process.

v3 of the patch was posted shortly before the holidays: [PATCH v3
00/19] bsd-user: Add system call and mips/arm support.

-Ed

Re: [Qemu-devel] [PATCH v2 00/19] bsd-user: Add system call and mips/arm support.

[Ed Maste]

On 27 November 2013 06:29, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 26/11/2013 22:01, Ed Maste ha scritto:
 On 8 November 2013 11:33, Stacey Son s...@freebsd.org wrote:
 [v2]

 - Rebases to 1.7.0-rc0. (Requires, however, Andreas Tobler's patch to
   build: see
   http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg0.html)
 - Fixes deadlock in the _umtx_op() system call handler.
 - Fixes race condition in mmap() system call handler.
 - Makes qemu-mips (o32) usable.
 - A small code clean up to the ARM cpu_loop().
 - Fixes comment in arm-bsd-user.mak to match filename.
 - Fixes symbol conflicts with FreeBSD's libcrypto for static link.

 Ping.

 This is a large change in an area that hasn't had a lot of activity of
 late; what are the next steps here?

 We're now in hard freeze, so the next step is to wait for 1.8 to be
 released.

 I reviewed the parts out of bsd-user, and had only one question.

Ok, 1.7's now out, and we'll sort out the HOST_ABI vs. HOST_VARIANT
question.  What's our next step after that?

Re: [Qemu-devel] [PATCH v2 00/19] bsd-user: Add system call and mips/arm support.

[Ed Maste]

On 8 November 2013 11:33, Stacey Son s...@freebsd.org wrote:
 [v2]

 - Rebases to 1.7.0-rc0. (Requires, however, Andreas Tobler's patch to
   build: see
   http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg0.html)
 - Fixes deadlock in the _umtx_op() system call handler.
 - Fixes race condition in mmap() system call handler.
 - Makes qemu-mips (o32) usable.
 - A small code clean up to the ARM cpu_loop().
 - Fixes comment in arm-bsd-user.mak to match filename.
 - Fixes symbol conflicts with FreeBSD's libcrypto for static link.

Ping.

This is a large change in an area that hasn't had a lot of activity of
late; what are the next steps here?

-Ed

Re: [Qemu-devel] [PATCH 01/18] bsd-user: refresh freebsd system call numbers

[Ed Maste]

On 16 October 2013 10:36, Stacey Son s...@freebsd.org wrote:
 Update FreeBSD system call numbers in freebsd/syscall_nr.h.

 Signed-off-by: Stacey Son s...@freebsd.org

Reviewed-by: Ed Maste ema...@freebsd.org

Re: [Qemu-devel] [RFC] Policy for supported hosts/platforms

[Ed Maste]

I was originally going to host the FreeBSD 9 buildbot myself (in a VM)
but I now have an offer for permanent amd64/x86-64 FreeBSD 9 and
FreeBSD 10 buildbots.

It seems Christian is not available; is there anyone else who can set
up a buildslave account (ideally both FreeBSD 9 amd64 and FreeBSD 10
amd64)?

On 10 September 2013 03:44, Stefan Hajnoczi stefa...@gmail.com wrote:
 On Mon, Sep 09, 2013 at 02:15:57PM -0400, Ed Maste wrote:
 On 17 July 2013 20:07, Ed Maste ema...@freebsd.org wrote:

  On 8 July 2013 11:15, Ed Maste ema...@freebsd.org wrote:
  
   Ok, as soon as I can get a password (after the buildbot disk space
   issues are sorted out) I'll contribute a FreeBSD 9 amd64 builder.
 
  It seems the disk space / inode issue is resolved; is there anything
  further still in the way of adding a FreeBSD builder?
 

 Ping.

 Christian: Can you add a new buildslave account for FreeBSD 9 amd64 and
 send Ed the connection details?

 Stefan

Re: [Qemu-devel] [RFC] Policy for supported hosts/platforms

[Ed Maste]

On 17 July 2013 20:07, Ed Maste ema...@freebsd.org wrote:

 On 8 July 2013 11:15, Ed Maste ema...@freebsd.org wrote:
 
  Ok, as soon as I can get a password (after the buildbot disk space
  issues are sorted out) I'll contribute a FreeBSD 9 amd64 builder.

 It seems the disk space / inode issue is resolved; is there anything
 further still in the way of adding a FreeBSD builder?


Ping.

Re: [Qemu-devel] [Qemu-trivial] [PULL trivial 0/5] trivial patches for 2013-07-19

[Ed Maste]

On 19 July 2013 05:11, Michael Tokarev m...@tls.msk.ru wrote:
 This is another trivial-patches pull request.  This time
 we have just 5 patches accumulated in two (!) weeks period.
 Please consider apply.
...
 Michael Tokarev (2):
   slirp: remove mbuf(m_hdr,m_dat) indirection

Any idea when this might get pulled?  The FreeBSD build is broken
until this slirp fix makes it in.

Re: [Qemu-devel] [Qemu-trivial] [PULL trivial 2/5] slirp: remove mbuf(m_hdr, m_dat) indirection

[Ed Maste]

On 19 July 2013 05:11, Michael Tokarev m...@tls.msk.ru wrote:
 ---
  slirp/mbuf.h |   51 ++-
  slirp/tcp_subr.c |   12 ++--
  2 files changed, 24 insertions(+), 39 deletions(-)

Tested-by: Ed Maste ema...@freebsd.org

Re: [Qemu-devel] [Qemu-trivial] [PULL trivial 0/5] trivial patches for 2013-07-19

[Ed Maste]

On 24 July 2013 09:32, Anthony Liguori aligu...@us.ibm.com wrote:
 Ed Maste ema...@freebsd.org writes:

 On 19 July 2013 05:11, Michael Tokarev m...@tls.msk.ru wrote:
 This is another trivial-patches pull request.  This time
 we have just 5 patches accumulated in two (!) weeks period.
 Please consider apply.
 ...
 Michael Tokarev (2):
   slirp: remove mbuf(m_hdr,m_dat) indirection

 Any idea when this might get pulled?  The FreeBSD build is broken
 until this slirp fix makes it in.

 Two days ago.

Ahh, sorry - I was somehow pulling from a local mirror that got stuck.

Re: [Qemu-devel] [Qemu-trivial] [PATCH] slirp: reorder include to fix FreeBSD build failure

[Ed Maste]

On 17 July 2013 04:54, Michael Tokarev m...@tls.msk.ru wrote:
 17.07.2013 12:32, Jan Kiszka wrote:
 No problem, as Peter already said. Please provide an according patch.

 http://thread.gmane.org/gmane.comp.emulators.qemu/221949/focus=221975
  (an attachtment there)
 http://git.corpit.ru/?p=qemu.git;a=commitdiff;h=2915c3b20260b1a653fced3b584d0c2b012880dc

I'm happy with Michael's patch.

Re: [Qemu-devel] [RFC] Policy for supported hosts/platforms

[Ed Maste]

On 8 July 2013 11:15, Ed Maste ema...@freebsd.org wrote:

 Ok, as soon as I can get a password (after the buildbot disk space
 issues are sorted out) I'll contribute a FreeBSD 9 amd64 builder.

It seems the disk space / inode issue is resolved; is there anything
further still in the way of adding a FreeBSD builder?

Re: [Qemu-devel] [Qemu-trivial] [PATCH] slirp: reorder include to fix FreeBSD build failure

[Ed Maste]

On 13 July 2013 05:12, Michael Tokarev m...@tls.msk.ru wrote:

 Remaining:

 struct mbuf {
 union M_dat {
 charm_dat_[1]; /* ANSI don't like 0 sized arrays */
 char*m_ext_;
 } M_dat;
 };

 #define m_dat   M_dat.m_dat_
 #define m_ext   M_dat.m_ext_

 This can be done by using an unnamed union, ie, by omitting


Yeah, struct mbuf and those #defines date back to the beginning of BSD
networking.

I think we're probably unconcerned with a slirp upstream at this point, so
such a change seems reasonable.  I'm not sure that anonymous union support
is universal across all compilers used to build QEMU though - do you know?

[Qemu-devel] [PATCH] slirp: reorder include to fix FreeBSD build failure

[Ed Maste]

Signed-off-by: Ed Maste ema...@freebsd.org
---
The issue comes from slirp/mbuf.h #defining m_flags, which conflicts with
a header included via semaphore.h on FreeBSD.

I'm not sure exactly when this broke; I assume that it used to work because
something previously caused the conflicting header to be included earlier,
and that has now been removed.

 slirp/slirp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/slirp/slirp.c b/slirp/slirp.c
index 80b28ea..231afc8 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -24,8 +24,8 @@
 #include qemu-common.h
 #include qemu/timer.h
 #include sysemu/char.h
-#include slirp.h
 #include hw/hw.h
+#include slirp.h
 
 /* host loopback address */
 struct in_addr loopback_addr;
-- 
1.7.11.5

Re: [Qemu-devel] [RFC] Policy for supported hosts/platforms

[Ed Maste]

On 3 July 2013 04:57, Stefan Hajnoczi stefa...@gmail.com wrote:
 On Tue, Jul 02, 2013 at 09:35:41AM +0200, Christian Berendt wrote:
 On 07/02/2013 09:31 AM, Stefan Hajnoczi wrote:
 I think the solution is to add another buildmaster administrator.  I
 believe Christian offered that in the past.

 Sure. I think it would be the best to have an additional admin
 directly involved in the project.

 I sent a private email to set up buildbot admin access.

Ok, as soon as I can get a password (after the buildbot disk space
issues are sorted out) I'll contribute a FreeBSD 9 amd64 builder.

Re: [Qemu-devel] [RFC] Policy for supported hosts/platforms

[Ed Maste]

On 1 July 2013 07:47, Stefan Hajnoczi stefa...@gmail.com wrote:

 Yes, Christian Berendt admins the buildmaster.  How much time has passed
 since you emailed?

June 7; perhaps the email was lost.  I would like to start with a
FreeBSD 9.x x86_64 instance, potentially adding i386 and FreeBSD
10-CURRENT to the mix later.

-Ed

Re: [Qemu-devel] [PATCH 2/2] qemu-thread: add TLS wrappers

[Ed Maste]

 On 1 July 2013 05:35, Stefan Hajnoczi stefa...@redhat.com wrote:
 From: Paolo Bonzini pbonz...@redhat.com

 Fast TLS is not available on some platforms, but it is always nice to
 use it.  This wrapper implementation falls back to pthread_get/setspecific
 on POSIX systems that lack __thread, but uses the dynamic linker's TLS
 support on Linux and Windows.

The most recent version of this patch posted by Paolo that I see has:

+#if defined(__linux__) || defined(__FreeBSD__)
+#define DECLARE_TLS(type, x) \

while this one has only __linux__.  Do you mind picking up that
change, if this is likely to make it in via your work?

Re: [Qemu-devel] [PATCH 2/2] qemu-thread: add TLS wrappers

[Ed Maste]

On 1 July 2013 15:25, Peter Maydell peter.mayd...@linaro.org wrote:
 Does any OS have a __thread which compiles but is broken, or can
 we just have a configure test for this? That would let MacOSX+clang
 use __thread.

I believe this was recently the case on NetBSD - code with __thread
would build, but fail at run time.  I think this applies to NetBSD 5.0
and earlier, but I see that TLS support is listed in the 6.0 release
notes.  So perhaps a __thread configure test with an override for the
known-failing case(s).

Re: [Qemu-devel] [Qemu-trivial] [PATCH] tls.h: Enable TLS on FreeBSD

[Ed Maste]

On 28 June 2013 06:34, Michael Tokarev m...@tls.msk.ru wrote:
 24.06.2013 23:21, Ed Maste wrote:
 Signed-off-by: Ed Maste ema...@freebsd.org
 ---
 I have had this in a local tree for some time, and it is needed by the
 BSD-user work that is now being proposed.

 So I'm not applying this to -trivial, because it caused quite some
 discussion.  If nevertheless it's okay to apply it, please let me know.

 /mjt

An objection seemed to be that it is not really needed yet, but as
pointed out by Peter this isn't really the case.  This patch brings us
(FreeBSD) in line with per-thread data semantics on Linux and is used
by qemu system emulation as well.

The other discussion was all around platforms unaffected by this
change (OpenBSD, Windows); I don't see it as an argument either for or
against this change.  So I think it's reasonable to go in.

Re: [Qemu-devel] [Qemu-trivial] [PATCH] tls.h: Enable TLS on FreeBSD

[Ed Maste]

On 28 June 2013 09:05, Peter Maydell peter.mayd...@linaro.org wrote:
 On 28 June 2013 14:03, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 28/06/2013 14:54, Ed Maste ha scritto:
 An objection seemed to be that it is not really needed yet, but as
 pointed out by Peter this isn't really the case.  This patch brings us
 (FreeBSD) in line with per-thread data semantics on Linux and is used
 by qemu system emulation as well.

 It brings it in line with Linux, even though FreeBSD has the same need
 for TLS as OpenBSD and Windows (i.e. none).  In other words, we go from
 two cases (need TLS and uses it, has no TLS and doesn't need it) to
 three (we add uses TLS with no need for it).

 I don't understand what you mean by no need for it. We are
 already multithreaded in system mode, so this is simply
 making FreeBSD do the same thing as Linux. That seems like a
 clear improvement to me.

I agree; even if this is a hack, it's a well-tested one.  Indeed, even
on a FreeBSD host most users already have this change, as they have
built from ports or used prebuilt packages.

Re: [Qemu-devel] [Qemu-trivial] [PATCH] tls.h: Enable TLS on FreeBSD

[Ed Maste]

On 28 June 2013 11:11, Paolo Bonzini pbonz...@redhat.com wrote:
 And of course if bsd-user supported 1:1 mapping between guest and host
 threads on FreeBSD, cpu_single_env would have to be thread-local.

This is the case for the bsd-user work that Stacey posted at the
beginning of the week and is currently being revised after the initial
round of comments.

Can you comment on how quickly your tls work is expected to arrive?
We'll have to rebase on top of it, if it's in the next few days or so.
 If it's longer than that we'll need this change as a prerequisite for
the bsd-user work.

After Peter suggested splitting this change out I sent it to -trivial
because I already had it in a test tree, and it has no effect on
non-FreeBSD hosts.  If it's really objectionable right now we can
include it with v2 of the bsd-user series.

Re: [Qemu-devel] [PATCH 05/30] exec: do not use qemu/tls.h

[Ed Maste]

On 28 June 2013 14:26, Paolo Bonzini pbonz...@redhat.com wrote:

 +/* This is thread-local depending on __linux__ because:

Is the comment perhaps unchanged from an earlier revision that used a
different test?  It seems odd to me to reference __linux__ here.

 + *  - the only -user mode supporting multiple VCPU threads is linux-user
 + *  - TCG system mode is single-threaded regarding VCPUs
 + *  - KVM system mode is multi-threaded but limited to Linux
 + */
 +#if defined CONFIG_KVM || (defined CONFIG_USER_ONLY  defined 
 CONFIG_USE_NPTL)

Also, in discussion on the FreeBSD bsd-user patch set the suggestion
was made that we do away with a flag, and just have thread support
always enabled.  Would you suggest this test then become KVM ||
(USER_ONLY  (USE_NPTL || __FreeBSD__))?

Re: [Qemu-devel] [PATCH v3] configure: Simplify alternate .text segment

[Ed Maste]

On 21 June 2013 22:10, Richard Henderson r...@twiddle.net wrote:
 For bsd-user and linux-user emulation modes QEMU needs to be linked at an
 alternate .text segment address, so that it's out of the way of the guest
 executable.  Instead of including modified linker scripts for each arch,
 just set the address with -Ttext-segment if supported, or by using sed to
 edit the default linker script.

 Cc: Ed Maste ema...@freebsd.org
 Signed-off-by: Richard Henderson r...@twiddle.net
 ---
  configure | 48 +++-
  2 files changed, 31 insertions(+), 18 deletions(-)
 --

 Changes v2-v3:
   * Move the check for textseg_ldflags much earlier in the configure file,
 so that we've not got cflags invalid for configure time.  Plus, the
 check (and generated ld script) only gets done once, not once per
 target directory.
   * Remove ia64 from the hosts that get relocation
   * Handle s390x like s390.

Thanks for cleaning this up.  Tested on x86_64 FreeBSD with base
system (old) binutils.

Acked-by: Ed Maste ema...@freebsd.org
Or if you prefer, for my contribution to this version,
Signed-off-by: Ed Maste ema...@freebsd.org

[Qemu-devel] [PATCH] tls.h: Enable TLS on FreeBSD

[Ed Maste]

Signed-off-by: Ed Maste ema...@freebsd.org
---
I have had this in a local tree for some time, and it is needed by the
BSD-user work that is now being proposed.

As an aside, an abstraction was recently proposed for Open vSwtich that
can use any of _Thread_local, __thread, or pthread_getspecific() which
may make a convenient reference for someone wishing to implement one of
the TODOs: http://openvswitch.org/pipermail/dev/2013-June/028665.html

 include/qemu/tls.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/qemu/tls.h b/include/qemu/tls.h
index b92ea9d..ae7d79d 100644
--- a/include/qemu/tls.h
+++ b/include/qemu/tls.h
@@ -38,7 +38,7 @@
  * TODO: proper implementations via Win32 .tls sections and
  * POSIX pthread_getspecific.
  */
-#ifdef __linux__
+#if defined(__linux__) || defined(__FreeBSD__)
 #define DECLARE_TLS(type, x) extern DEFINE_TLS(type, x)
 #define DEFINE_TLS(type, x)  __thread __typeof__(type) tls__##x
 #define tls_var(x)   tls__##x
-- 
1.7.11.5

[Qemu-devel] [RFT PATCH v2] configure: Simplify alternate .text segment

[Ed Maste]

For bsd-user and linux-user emulation modes QEMU needs to be linked at an
alternate .text segment address, so that it's out of the way of the guest
executable.  Instead of including modified linker scripts for each arch,
just set the address with -Ttext-segment if supported, or by using sed to
edit the default linker script.

Note that ldscripts/alpha.ld was already unused prior to this change, as
it was handled by the default placement of the application is fine case.

Signed-off-by: Ed Maste ema...@freebsd.org
---
Changes from v1:
 - Drop removal of ldscripts from the patch for now.  They remain unused
   with v2 and can be removed later, but this makes the patch smaller
   during review and testing.
 - Don't require knowledge of the default .text address, as suggested by
   Richard Henderson.
 - Use configure's existing compile_prog to test for acceptance of the
   linker flag rather than a hack that fails on current binutils versions.

 configure|  37 +---
diff --git a/configure b/configure
index ad32f87..b3025df 100755
--- a/configure
+++ b/configure
@@ -4072,9 +4072,6 @@ if test $gcov = yes ; then
   echo GCOV=$gcov_tool  $config_host_mak
 fi
 
-# generate list of library paths for linker script
-$ld --verbose -v 2 /dev/null | grep SEARCH_DIR  config-host.ld
-
 # use included Linux headers
 if test $linux = yes ; then
   mkdir -p linux-headers
@@ -4437,21 +4434,35 @@ if test $gprof = yes ; then
   fi
 fi
 
-if test $ARCH = tci; then
-  linker_script=
-else
-  linker_script=-Wl,-T../config-host.ld 
-Wl,-T,\$(SRC_PATH)/ldscripts/\$(ARCH).ld
-fi
-
 if test $target_linux_user = yes -o $target_bsd_user = yes ; then
+  textseg_addr=
   case $ARCH in
-  alpha | s390x | aarch64)
-# The default placement of the application is fine.
+  arm | hppa | i386 | ia64 | m68k | ppc | ppc64 | s390 | sparc | sparc64 | 
x86_64)
+textseg_addr=0x6000
 ;;
-  *)
-ldflags=$linker_script $ldflags
+  mips)
+textseg_addr=0x40
 ;;
   esac
+  if [ -n $textseg_addr ]; then
+cat  $TMPC EOF
+int main(void) { return 0; }
+EOF
+try_ldflags=-Ttext-segment=$textseg_addr
+if compile_prog  $try_ldflags; then
+  ldflags=$ldflags $try_ldflags
+else
+  # In case ld does not support -Ttext-segment, edit the default linker
+  # script via sed to set the .text start addr.  This is needed on FreeBSD
+  # at least.
+  $ld --verbose | sed \
+-e '1,/==/d' \
+-e '/==/,$d' \
+-e s/[.] = [0-9a-fx]* [+] SIZEOF_HEADERS/. = $textseg_addr + 
SIZEOF_HEADERS/ \
+-e s/__executable_start = [0-9a-fx]*/__executable_start = 
$textseg_addr/  config-host.ld
+  ldflags=$ldflags -Wl,-T../config-host.ld
+fi
+  fi
 fi
 
 echo LDFLAGS+=$ldflags  $config_target_mak

Re: [Qemu-devel] [RFC] Policy for supported hosts/platforms

[Ed Maste]

On 5 June 2013 10:04, Anthony Liguori aligu...@us.ibm.com wrote:

 Hi,

 Below is the coverage we currently have in buildbot.  It's not terribly
 complete but I suspect it does reflect what people are actually testing
 and care about.

 In terms of policy, we should consider buildbot coverage as a
 requirement for a platform/architecture to be fully supported.  Fully
 supported means (1) that code will be rejected/reverted if it breaks one
 of these platforms (2) breaking these platforms will be a release
 blocker.

Is the documentation at http://wiki.qemu.org/ContinuousIntegration
still current?  I emailed the contact listed there to offer a FreeBSD
build slave but haven't received a response.

The only remaining issue building from git head on FreeBSD is the text
segment relocation for bsd-user, for which I just sent a patch for
testing.