qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFC 8/9] tests: Add OpenBSD image


From: Brad Smith
Subject: Re: [Qemu-devel] [PATCH RFC 8/9] tests: Add OpenBSD image
Date: Thu, 24 Jan 2019 19:48:48 -0500
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 1/24/2019 11:52 AM, Daniel P. Berrangé wrote:

On Thu, Jan 24, 2019 at 05:10:19PM +0100, Philippe Mathieu-Daudé wrote:
On 1/24/19 4:56 PM, Kamil Rytarowski wrote:
On 24.01.2019 16:52, Philippe Mathieu-Daudé wrote:
On 8/16/17 9:21 AM, Fam Zheng wrote:
The image is prepared following instructions as in:

https://wiki.qemu.org/Hosts/BSD

Signed-off-by: Fam Zheng <address@hidden>
---
  tests/vm/openbsd | 45 +++++++++++++++++++++++++++++++++++++++++++++
  1 file changed, 45 insertions(+)
  create mode 100755 tests/vm/openbsd

diff --git a/tests/vm/openbsd b/tests/vm/openbsd
new file mode 100755
index 0000000000..d37ff83a59
--- /dev/null
+++ b/tests/vm/openbsd
@@ -0,0 +1,45 @@
+#!/usr/bin/env python
+#
+# OpenBSD VM image
+#
+# Copyright (C) 2017 Red Hat Inc.
+#
+# Authors:
+#  Fam Zheng <address@hidden>
+#
+# This work is licensed under the terms of the GNU GPL, version 2.  See
+# the COPYING file in the top-level directory.
+#
+
+import os
+import sys
+import logging
+import subprocess
+import tempfile
+import time
+import basevm
+
+class OpenBSDVM(basevm.BaseVM):
+    name = "openbsd"
+    BUILD_SCRIPT = """
+        set -e;
+        cd $(mktemp -d /var/tmp/qemu-test.XXXXXX);
+        tar -xf /dev/rsd1c;
+        ./configure --cc=x86_64-unknown-openbsd6.1-gcc-4.9.4 
--python=python2.7 {configure_opts};
+        gmake -j{jobs};
+        # XXX: "gmake check" seems to always hang or fail
+        #gmake check;
OK, Now it makes more sense...

After spending various hours trying to fix various issues on OpenBSD, I
notice that we never ran tests on this OS.
The only binary I can run is qemu-img, the rest seems useless.
I'll summarize in a different thread.

Is this W^X related?
Part of it could be but I'm not sure.

The 6.1 VM provided by Fam has /usr/local mounted with wxallowed, I
tried building/running there and nothing changed, mmap() still returns
ENOTSUP:
ENOTSUP from mmap is certainly what you'd expect from the W^X  scenario

   https://undeadly.org/cgi?action=article&sid=20160527203200

  "W^X violations are no longer permitted by default.  A kernel log message
   is generated, and mprotect/mmap return ENOTSUP.  If the sysctl(8) flag
   kern.wxabort is set then a SIGABRT occurs instead, for gdb use or coredump
   creation."

Yes, this policy change was introduced with 6.0.

Our ports tree has an option which results in the QEMU binaries being linked with "-z wxneeded".




reply via email to

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