| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have an issue where qemu is being starved of resources on our autobuilders.
We can't raise its priority without special capacilties, therefore add a hook
which if present can allow this to happen using an executable
"~/runqemu-renice".
(From OE-Core rev: 829443b3fafa000e330c06ebb144641bd2d20ad1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 141a3c9ce93bc3d526303021ecf0460c6e9fea8a)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The autobuilder managed to pass the nographic option with "sdl gl" due
to a problem elsewhere. It would have been useful for runqemu to have
errored rather than passing conflicting options to qemu. Add an
error for this invalid usecase.
(From OE-Core rev: e62c8207fa47ff4e325529ea84e0d51710deaa3c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 377a6ffbcba0d3c5ede470c989756c4d1636873f)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
runqemu help reports that gtk or sdl option is needed with gl or gl-es
option. But if user forgot to add gtk or sdl option, then gl or gl-es
options were silently skipped.
(From OE-Core rev: bec0a45393d968251059f5075add2cf633aecd1a)
Signed-off-by: Vasyl Vavrychuk <vvavrychuk@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 4d1e93d4bf013bb0c48032bfda43f77c5aba9ecf)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Content of the optional parameter will be appended to the rootfs-device
in the qemu configuration, in case QB_ROOTFS_OPT is not specified.
By default this is empty.
Example use cases are:
Defining 'readonly' when using squashfs, so multiple instances of qemu
can share the same base image, something that cannot be done by just
specifying 'snapshot'.
Defining 'bootindex=0' which helps to get past the EFI shell in
ovmf-binary. This also enables the use case of running WIC images with
EFI bootloader through the testimage.bbclass.
(From OE-Core rev: 1a5cb1bd56be2b784208516a7c73c49906c7022f)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit e9b8c194636cb5505774a2a71bf54450580dd5b8)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since kernel commit b24ee6c64ca7 ("NFS: allow deprecation of NFS UDP protocol"),
NFS UDP has been disabled by default due to the potential data corruption caused
by fragmentation during high loads. So now we cannot boot up with nfs mode and
default kernel.
We'd better turn to use TCP accordingly.
(From OE-Core rev: 73a54595d8ddf237d685ea9cb46df0cecac0280d)
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Emulating more than one network interface with runqemu is a bit tricky,
but possible. For example, the following leads to an emulated device with
eth0 and eth1:
QB_NETWORK_DEVICE_prepend = " \
-device virtio-net-device,mac=52:54:00:12:34:03 \
"
or
QB_NETWORK_DEVICE_append = " \
-device virtio-net-pci,mac=52:54:00:12:34:03 \
"
When booting Qemu with two NICs, the kernel does not know which
interface the specified ip=192.168.7.... command line argument
should be applied. This delays the boot process for a very long
time and a guest wihtout IP configuration.
This add two new configuraton parameters to runqemu:
QB_CMDLINE_IP_SLIRP and QB_CMDLINE_IP_TAP to explicitely specify the ip=
kernel command line arguments for tap and slirp mode.
Note: Simply adding "::eth0" broke some builds on the Yocto autobuilder.
(From OE-Core rev: 59bfdc331c1494c05ab38804b281878a1f571f6d)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Qemu supports attaching the virtual machine to an existing network
bridge interface via the qemu-bridge-helper program (as long as the
system is correctly configured to give the user permissions). Add
support for runqemu to do this also via the "bridge=<INTERFACE>"
argument. Note that for this to work correctly, the host
qemu-bridge-helper must be used, not the one that might have been built
by qemu-native. In order for qemu to correctly find this program, a
qemu-oe-bridge-helper program has been added to qemu-helper-native, and
runqemu will use this helper as the bridge helper. The helper will look
for the host qemu-bridge-helper first by looking in the
QEMU_BRIDGE_HELPER environment variable, then by search common paths
where the helper is installed.
(From OE-Core rev: 9e7b38c61c6b84b7f137c733ac5da9414025693d)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement new QB_DRIVE_TYPE="/dev/vdb" which falls back
to virtio block device emulated by qemu.
That is needed to support following qemu command line:
-drive id=disk0,file=%s,if=none,format=%s \
-device virtio-blk-device,drive=disk0'
Real use case is arm64 emulation with qemu with atf+optee+uboot,
so that uboot driver sees this disk and able to load from it.
(From OE-Core rev: 4d72cd395b2dd40dde1f3809e3ab255938e6a7a1)
Signed-off-by: Maxim Uvarov <maxim.uvarov@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Users may want to run qemu against a specific multiconfig instead of the
base configuration, so give them the ability to specify which config
should be used with the MULTICONFIG environment variable.
(From OE-Core rev: fda5d9b64fa310173ad949540c54fd693c4f7d3a)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we fail to run the command to generate the tap devices then we should
show a reasonable message and then exit, without showing a traceback.
"return 1" at this point in the code does nothing because the caller
doesn't check the return, so just use sys.exit().
(From OE-Core rev: 47e40fdd7dd58bde4e017e2375c16450fcb14eca)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is not a good idea to mix logging and calls to print() - if the
output is being captured the result can be that the two types of output
are not recorded contiguously; this could be observed if an error
occurred running runqemu from inside testimage:
---------- snip ----------
ERROR: core-image-minimal-1.0-r0 do_testimage: Output from runqemu:
runqemu - INFO - Continuing with the following parameters:
runqemu - INFO - Setting up tap interface under sudo
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
runqemu - ERROR - Setting up tap device failed:
Command '('sudo', '/home/paul/poky/poky/scripts/runqemu-ifup', '1000', '1000', '/home/paul/poky/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin')' returned non-zero exit status 1.
Run runqemu-gen-tapdevs to manually create one.
runqemu - INFO - Cleaning up
KERNEL: [/home/paul/poky/poky/build/tmp/deploy/images/qemux86-64/bzImage--5.2.20+git0+bd0762cd13_dd25a04fc5-r0-qemux86-64-20191205213021.bin]
MACHINE: [qemux86-64]
FSTYPE: [ext4]
ROOTFS: [/home/paul/poky/poky/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4]
CONFFILE: [/home/paul/poky/poky/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.qemuboot.conf]
---------- snip ----------
What we should see here is the KERNEL, MACHINE, etc. lines appearing
immediately after the "Continuing with the following parameters:" line
as they do when you run runqemu directly. If we put all of the lines
through the logger instead then it works properly.
(From OE-Core rev: ca64a3d490fbe1bf87c9f1dd6d87a1ecdeba8325)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
| |
(From OE-Core rev: c2564c7554a664ed26e010c67080fc784cff682a)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
The option 'highres=off' sneaked itself into the runqemu script for all
configurations, where the root filesystem type is not 'cpio' or 'cpio.gz'.
See: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13590
(From OE-Core rev: 3ecb6744402332f1ad143eb1eb6a94143e1700c8)
Signed-off-by: Joerg Vehlow <joerg.vehlow@aox-tech.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Some host distributions (opensuse for example) are using 'pkgconf',
which, unlike the original pkg-config, appends PKG_CONFIG_SYSROOT_DIR
to every directory from the .pc file.
(From OE-Core rev: 2d5ecc560dcfbaaaff307f8367d789d8c7e00dcf)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
This is a useful option but not documented in the help text.
(From OE-Core rev: 95bad67a802f956082bd0af5615c1dbaae01be0f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
This will allow not having to multiply these options for the sdl
frontend, instead combining them as needed.
(From OE-Core rev: 922eb5012364b1603338cfa617712b941e892bbf)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
(From OE-Core rev: c745185b0c112530d1a3d1c57feea0754d68ebb2)
Signed-off-by: Drew Moseley <drew.moseley@northern.tech>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the qemu default since qemu 2.2, is generally supported better,
and is recommended by upstream. It also has already been in use for arm/risc
and ovmf.
Additional information:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466
https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
'-vga virtio' emulated hardware remains in use when virgl is enabled via a runqemu override.
Also, adjust the error whitelist, as there is a number of new messages
coming from the drivers that are not actual errors.
(From OE-Core rev: 73cb104f3307736f4922f2e0c9648f9b2d3b3b6b)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a discussion about what amount of RAM is appropriate for a
default; the outcome was that for now it is still 256M. Some qemu machine
definitions have however set this to 512M so for the sake of
treating all architectures fairly, they are reset back to 256M.
Also runqemu is adjusted to use 256M if QB_MEM is not set at all.
http://lists.openembedded.org/pipermail/openembedded-core/2019-August/285900.html
(From OE-Core rev: 04c01b6cc5be3e6d45d0e04571640648a5655a8b)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Add support for specifying a BIOS the same way that the KERNEL variable
is specified. This includes specifying a QB_DEFAULT_BIOS variable.
(From OE-Core rev: fc2a2260aa22a81da6619b4affaf8ae0b5556a34)
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The EnrollDefaultKeys.efi application (distributed in ovmf-shell-image)
expects the hypervisor to provide a Platform Key and first Key Exchange
Key certificate.
For QEMU, this is done by adding an OEM string in the Type 11 SMBIOS
table. The string contains the EnrollDefaultKeys application GUID followed
by the certificate string. For now, the string is passed in the command
line until QEMU understands OEM strings from regular files (please see
https://bugs.launchpad.net/qemu/+bug/1826200).
If runqemu detects it is given an OVMF binary with support for Secure Boot
(i.e., ovmf.secboot* binaries), extract the certificate string from the
OvmfPkKek1.pem certificate and modify the command-line parameters to
provide the key. Such certificate is created when building OVMF with
support for Secure Boot.
Cc: Ross Burton <ross.burton@intel.com>
Cc: Patrick Ohly <patrick.ohly@intel.com>
(From OE-Core rev: 5e47316ae62f7632fb62bc3b8093ac42f9e3541c)
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when runqemu with slirp option on same host with different
users, it will report PermissionError: [Errno 13] Permission
denied: '/tmp/qemu-port-locks/2222.lock'
and during handle this exception, another exception happened since
key not exist. Fix by check if key exist first
(From OE-Core rev: 56f30e5377ebe5cc4544f081e001934706a0d8d3)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is race condition when multi qemu starting with slirp,
add lockfile for each port to avoid problem like:
runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: Could not set up host forwarding rule 'tcp::2323-:23'
[YOCTO #13364]
(From OE-Core rev: ceb3555a40ba06e58914465376aaf41392c12a7c)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
hdddirect was removed in commit 929ba563f1bc7195c4981b8e139c432b2cc388ea.
(From OE-Core rev: 7a91a9818057d69cba32db2428ffc1a1ebb3876e)
Signed-off-by: Daniel Ammann <daniel.ammann@bytesatwork.ch>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
wic images are handled as vmtype images. Starting qemu with "-kernel"
parameter and an image of type wic is not supported. Especially for
"-machine virt" the combination of wic with -kernel parameter would
be beneficial.
The new parameter QB_FSINFO allows to pass image type specific flags to
runqemu. QB_FSINFO is a space separated list of parameters. Parameters are
structured according to the following pattern: image-type:flag.
For now two parameters are supported:
- wic:no-kernel-in-fs
The wic image is treated as rootfs only image. A -kernel option is
passed to qemu.
- wic:kernel-in-fs
The wic image is treated as VM image including a bootloader and a
kernel. This is still the default behavior.
Example:
QB_DEFAULT_FSTYPE = "wic"
QB_FSINFO = "wic:no-kernel-in-fs"
QB_KERNEL_ROOT = "/dev/vda1"
QB_SYSTEM_NAME = "qemu-system-aarch64"
QB_MACHINE = "-machine virt"
...
[YOCTO #13336]
(From OE-Core rev: 2aa79a67affd22dfa37e4c2945c6ab0c86321f98)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases(such as the oeqa's qemurunner), we need to setup multi
serial devices via the '-serial 127.0.0.1:xx" and the order of them
is significant. The mixing use of "tcpserial" and "-serial 127.0.0.1:xx"
cause ambiguous issues and we can't fix it by only adjusting the order
of them. So add the support to pass multi ports to the tcpserial
parameter, this will make sure that the order of setting up the serial
is really what we want.
[YOCTO Bug 13309]
(From OE-Core rev: 766c3b56e5071b5a5a64e88df6d3abe5232dd958)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main issue is to make the x86 checks apply to x86 targets only. We may
end up with better checks on other architectures but this adapts the code to
allow for that and its still controlled by whether QB_CPU_KVM is set.
The code needed minor refactoring so the qemu-system-XXX name is set
earlier so the kvm code can use it.
(From OE-Core rev: 06c473a0127f19b76d0f647b87873944add1e331)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds SPDX license headers in place of the wide assortment of things
currently in our script headers. We default to GPL-2.0-only except for the
oeqa code where it was clearly submitted and marked as MIT on the most part
or some scripts which had the "or later" GPL versioning.
The patch also drops other obsolete bits of file headers where they were
encoountered such as editor modelines, obsolete maintainer information or
the phrase "All rights reserved" which is now obsolete and not required in
copyright headers (in this case its actually confusing for licensing as all
rights were not reserved).
More work is needed for OE-Core but this takes care of the bulk of the scripts
and meta/lib directories.
The top level LICENSE files are tweaked to match the new structure and the
SPDX naming.
(From OE-Core rev: f8c9c511b5f1b7dbd45b77f345cb6c048ae6763e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The subprocess.run was replaced by subprocess.check_call because
of compatibility support down to python 3.4. But we really don't
care about whether that command succeeds. Some user reports that
in some tmux environment, this command fails and gives some
unpleasant traceback output. So we use 'call' instead of 'check_call'
to avoid such problem.
(From OE-Core rev: c574aaf30c82ad397c0a6567b3cb52e7fb5d5829)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
If in the future GL is enabled for SDL frontend, or some other
frontend, it would be useful to be able to differentiate.
(From OE-Core rev: 36fd0a334cd6ed309cf96e445af83447070412a3)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
When Gtk+ and SDL are both enabled, qemu defaults to Gtk+.
This option allows to revert to the 'classic' frontend.
(From OE-Core rev: 34ee1d8b11ecc9bb7acaf9d61b8b7c954306f1ae)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
qemu has been using libepoxy for a long time, and libepoxy loads GL via dlopen()
only when instructed to.
(From OE-Core rev: d974e0e9a290d66b702e5ca1d01873282763437b)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
| |
(From OE-Core rev: cd4cdecd01c305b83a7483e44edb6ba856821148)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It only could be set as the following in the past:
QB_MEM = "-m 256"
Now it also can be set as:
QB_MEM = "-m 256M (or m)"
QB_MEM = "256M (or m)"
[YOCTO #11522]
(From OE-Core rev: ad246f5ce0652bd917d85884176baa746e1379ff)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed:
In meta/conf/machine/include/qemuboot-x86.inc:
QB_CPU_x86-64 = "-cpu core2duo"
$ runqemu qemux86-64 qemuparams="-cpu coreduo"
Check /proc/cpuinfo, it should use coreduo rather than core2duo since user
specifies it, but it doesn't, append qemuparams to the last can fix the
problem.
[YOCTO #11773]
(From OE-Core rev: a847dd7202a2c493788c45d11eb86866264af7a4)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Where possible pass lists instead of strings, don't use a subshell, and call
check*() instead of using Popen directly.
(From OE-Core rev: d2374623444752af1ad748ed36b68ea58f629bf6)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On python versions with close_fds=True (python 3.2 onwards), the tap
device lockfile isn't passed to the child process.
Since this guards against use of an active interface, we really want this
here, so pass it in pass_fds. This means if the parent exits early, the child
still holds the lock, avoiding messages like:
runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: could not configure /dev/net/tun (tap0): Device or resource busy
(From OE-Core rev: 17a0a067d597c445c5892ff9914e91a2187f7e09)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Various tweaks:
- Balance up the aquire/release functions
- Use debug messge for both acquiring and release message for consistency in logs
- Use None instead of an empty string
- Reset the value of the field if we don't have the lock any more
(From OE-Core rev: 58e48211f7cb44d959b571d449a94291c27535a5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
environment
MACHINE=qemux86-64 oe-selftest -r runqemu.RunqemuTests.test_boot_machine_slirp_qcow2
fails yet
oe-selftest -r runqemu.RunqemuTests.test_boot_machine_slirp_qcow2
with MACHINE in local.conf would work.
It turns out that:
runqemu slirp wic.qcow2 qemux86-64
works but:
MACHINE=qemux86-64 runqemu slirp wic.qcow2 qemux86-64
does not.
The reason are the misplaced return statements in runqemu, its skipping a block
of logic when MACHINE is set in the environment when it shouldn't. Fix this.
(From OE-Core rev: 98d113ae52cbbc88773a81a17b0933412a8e463b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
subprocess.run() was introduced in Python 3.5. We currently support down to
Python 3.4 so I've replaced it with subprocess.check_call() which is available
in that version.
(From OE-Core rev: 3a09cee5994ce65079dab1042e47e5eed4540bb9)
Signed-off-by: Michael Halstead <mhalstead@linuxfoundation.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Its currently not possible to have a console available whilst using qemu in graphics
mode. This is causing some issues for testing autobuilder bringup so all a "serialstdio"
mode to runqemu to accomodate this.
The existing serialstdio internal variable is renamed to allow the new user visible option.
(From OE-Core rev: 101b70d3c6a0a5a022d96dfdd21500b757c8fada)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current handling of SIGTERM is incorrect as the process pid returned
by Popen call with shell setting to True is actualy the shell instead of
the qemu process. So use shlex to split cmd so that we can avoid using
shell=True. This ensures the child process is the actual qemu process.
Also, as we install a SIGTERM handler, we need handle the situation of
qemu terminated by SIGTERM, otherwise we will get ERROR message in such
case.
Besides, we have a problem that after running qemu, the terminal's behavior
is incorrect regarding long lines or long commands. Long commands or long
outputs should appear in multiple lines, but they appear in the same line,
overriding previous output. Use `tput smam' to fix this problem.
(From OE-Core rev: e8acef383767cfd1ef0c3d3c45d9d6eb1c83b3e7)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It solves below error:
-- snip --
return 'qemu-system-%s' % qbsys
UnboundLocalError: local variable 'qbsys' referenced before assignment
-- snip --
[YOCTO #12846]
(From OE-Core rev: 519273f54c0b8a6fff36afeb7646d8e37717be22)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The warn method is deprecated. We should use the documented warning instead.
Quoting from the python's official doc:
"""
Note: There is an obsolete method warn which is functionally identical to warning.
As warn is deprecated, please do not use it - use warning instead.
"""
(From OE-Core rev: f467fd277eb77336097cfc0f5f329bdc8d0f70cb)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ runqemu qemumips64 core-image-minimal nographic qemuparams="-m 512"
...
[ 0.000000] Call Trace:
[ 0.000000] [<ffffffff801268c0>] clear_page+0x0/0x128
[ 0.000000] [<ffffffff80238158>] get_page_from_freelist+0xab8/0xc00
[ 0.000000] [<ffffffff80238964>] __alloc_pages_nodemask+0xdc/0xf68
[ 0.000000] [<ffffffff80239808>] __get_free_pages+0x18/0x70
[ 0.000000] [<ffffffff80122a4c>] setup_zero_pages+0x1c/0xb8
[ 0.000000] [<ffffffff80c7c998>] mem_init+0x54/0xa0
[ 0.000000] [<ffffffff80c74904>] start_kernel+0x204/0x4d8
[ 0.000000] [<ffffffff8091dfb0>] kernel_entry+0x0/0x40
[ 0.000000] Code: 02002025 1000f8d9 8e634d7c <34860f80> cc9e0000
cc9e0020 cc9e0040 cc9e0060 cc9e0080
[ 0.000000]
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
...
OE uses qemumips to simulate a Malta board by default.
As upstream qemu introduced:
https://git.qemu.org/?p=qemu.git;a=commit;h=94c2b6aff43cdfcfdfb552773a6b6b973a72ef0b
The Malta board can support up to 2GiB of RAM which should
be able to boot a Linux kernel built with CONFIG_HIGHMEM
enabled and passing "-m 2048" to QEMU and appending the
following kernel parameters:
...
mem=256M@0x0 mem=256M@0x90000000 mem=1536M@0x20000000
...
But the following commit in kernel broke above mem=X@Y setting
which added the memory as reserved memory area.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
...
commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411
Author: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Date: Wed Nov 23 14:43:49 2016 +0100
MIPS: fix mem=X@Y commandline processing
...
So remove `mem=*' to disable user-defined physical RAM map
which let kernel itself caculates memory ranges.
Author: Hongxu Jia <hongxu.jia@windriver.com>
[ Merge the two fixes for qemumips32 and qemumips64 into one patch,
and make it support all mips cases ]
(From OE-Core rev: 0220cb34a91658ecc3782ec1a4700dcb5ece37d8)
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add SIGTERM handler so that runqemu could clean things up correctly
when receving such signal.
This problem was originally observed when running testimage. On
some hosts, after running testimage task, the user has to manually
operate on the tap interface (e.g. `sudo ip link del tap0') in order
for the next runqemu command to launch successfully.
The problem is about runqemu, SIGTERM and network manager on the host.
In testimage task, the runqemu process will receive SIGTERM. In such
situation, its cleanup() function is not run, resulting in tap interface
not cleaned up. On some hosts, the network manager will bring down the
tap interface automatically, thus this problem. I saw this problem on
Fedora21.
I think we'd better just clean up the tap interface ourselves.
So this patch adds to runqemu a SIGTERM handler, in which the actual
qemu process is terminated and other things cleaned up.
(From OE-Core rev: 02709d4709c56f9b9095e3555da35b659b03a8a3)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
On pre 4.15 host kernels, an APIC window emulation bug can cause qemu
to hang. On 64 bit we can use the x2apic, for 32 bit, we just have to
disable the other timer sources and rely on kvm-clock.
[YOCTO #12301]
(From OE-Core rev: 82e67b82ea8e12aa0b7b9db1d84fec0436dec71b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the runqemu script to allow the user to specify a device tree
to boot when calling runqemu.
This involves creating a seperate check_dtb() function incase the user
has specified 'none' for the kernel but still wants a device tree.
(From OE-Core rev: 867ac1370b294bfd1ee31f94abb63688f77081a1)
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Reviewed-by: Ben Levinsky <ben.levinsky@xilinx.com>
Cc: Ben Levinsky <ben.levinsky@xilinx.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the runqemu script to allow the user to specify a Kernel to boot
when calling runqemu.
(From OE-Core rev: eaf2793a98cb27d82561da0f8993f2b4b304ecc2)
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Cc: Ben Levinsky <ben.levinsky@xilinx.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
This makes debug easier.
(From OE-Core rev: a453639e19fb2a9f9fb63fddd0b3ee26c0116d91)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|