| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
Measure and display the time it takes to copy the rootfs to its new
location (usually in tmpfs) to try to understand whether it sometimes takes
a lot of time on the autobuilders.
(From OE-Core rev: be213114c1349e02ca48fd617a6c3badae8aa101)
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Each of the cores is mapped to a thread on the host, this
should speed up things inside qemu which can take advantage of that.
(From OE-Core rev: 56f98d12a79585a4d4c459160f39403e05b620a5)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
We need to cleanup snapshot files if we make a copy of them to ensure
the tmpfs doesn't run out of space. There is already NFS code needing
this so make it a generic code path.
(From OE-Core rev: a3e0eec5a4785a0c4859455eb10b43aa832e606d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a working theory that IO queues on the autobuilder are impacting
runtime testing under qemu, particularly async writes which inice does not
influence. We already pass the snapshot option to qemu which copies the
image and runs out of the copy. Add in the ability to copy the image to
a specificed location which can be a tmpfs. This means that writes to the
image would no longer be blocked by other writes to disk in the system.
Preliminary tests show that this does improve the qemu errors at the expense
of sometimes showing qemu startup timeouts as on a loaded system with a large
test image, it can take longer than 120s to copy the image to tmpfs. Having
a most consistent failure mode for loaded tests is probably desireable though.
(From OE-Core rev: fd1c26ab426c3699ffd8082b83d65a84c8eb8bff)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Some options such as egl-headless are fully compatible with it, so
there is no need to quit.
(From OE-Core rev: 66d11106f9e76d19e397ba3d14c3a22726033567)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Passing 'novga' only adds '-vga none' to the qemu commandline and does
not prevent other vga devices from being added, contrary to the
documentation/help. Clean-up the vga logic and add the ability to
prevent other vga devices from being added.
(From OE-Core rev: 9f8d049dbbe0b1760979d9f3b745124abfc54c90)
Signed-off-by: Jon Mason <jon.mason@arm.com>
Change-Id: I7ff8f9f3e419ce8bae3f3847d75f9275ca30406a
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some platforms do not use ttyS* for their serial consoles (e.g., qemuarm
and qemuarm64). The hardcoding of this can cause issues. Modify
runqemu to use the serial consoles defined in SERIAL_CONSOLES instead of
hardcoding.
(From OE-Core rev: 9dea4cd2f9f46ab3a75562639a22d8f56b4d26af)
Signed-off-by: Jon Mason <jon.mason@arm.com>
Change-Id: I746d56de5669c955c5e29d3ded70c0a4d3171f17
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new runqemu field for VGA devices. Currently, these are being set
in QB_OPT_APPEND, which can make them difficult to override if importing
the config file into another one.
(From OE-Core rev: 695c98b6522be4373806c154a2999eaeef205556)
Signed-off-by: Jon Mason <jon.mason@arm.com>
Change-Id: I8cb9527954c5b06c083c42fe2466cb3338584b7d
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
bin is not an acceptable format for qemu and will throw an error is set.
The correct format in this case is raw.
(From OE-Core rev: cd279aeb986b4676ea8ecb1e7b12c7e29e83460a)
Signed-off-by: Jon Mason <jon.mason@arm.com>
Change-Id: I9d78e356d39ecb15bef886c19870b029d9badd65
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using nographic, explicitly disabling vga is needed some cases
since some qemu firmware (OpenFirmware ) defaults to std vga, and
when vga is enabled then it disables output to serial and redirects
that to vga which is by design, hwoever we expect the console output
to go to serial when using nographic, therefore its important to
disable vga with nographic especially on qemu based ppc platforms
(From OE-Core rev: eabbdb3c4f78ab23348a6b988f59d9d98b5e2c7c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
(From OE-Core rev: fafa2fe6d4d40ab6ba7d39b397d2bde9eb0d6b72)
Signed-off-by: Sinan Kaya <okaya@kernel.org>
Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
RNG passthru has been enabled on all qemu machines but its being added
to each one of them, with this patch its turned into QB variables which
defaults to host passthru, yet it can be overridden if needed via
machine or config metadata if needed.
(From OE-Core rev: 26dd24506ef36088e17f999ce5489dc4b72194e8)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
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: 141a3c9ce93bc3d526303021ecf0460c6e9fea8a)
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: 377a6ffbcba0d3c5ede470c989756c4d1636873f)
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: 4d1e93d4bf013bb0c48032bfda43f77c5aba9ecf)
Signed-off-by: Vasyl Vavrychuk <vvavrychuk@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
The code should check /dev/vhost-net instead of /dev/kvm. And
the permission check logically belongs to the part when kvm-vhost
is enabled. Also fix the URL to point to the correct wiki page.
(From OE-Core rev: 53bdf2d20077921bdf83641c365d60d85174f5b5)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no way to use runqemu and turn off the no-reboot flag with a
command line argument. If someone really wants it back it can be
added with the qemuparams="" argument.
Also if you use the "halt -p" from user space, the qemu will exit when
it is complete. It is impossible to test self deploying image with
runqemu if you cannot reboot the device. One might argue that you can
run runqemu in a loop, but that defeats the purpose of having a
wrapper around a tool that already does what is needed in the first
place.
For the vmtype images, the -no-reboot flag should not be added.
(From OE-Core rev: 6d07a72356f9a8ea76b6cda9159d3ca4743028d9)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Major update after v4.2.
Changes:
- os_find_datadir() was changed after the v4.2 release
causing v5.0 to not find the bios and not boot the
image. Fix is sent to upstream qemu.
See: qemu/find_datadir.patch
- v5.0 binary had host contamination for dynamically linked
libraries, "--extra-ldflags='${LDFLAGS}'" in EXTRA_OECONF
resolved the issue
- bluetooth code was removed: qemu.git$ git show 1d4ffe8dc7
hence removed PACKAGECONFIG[bluez]
- -show-cursor qemu option is now deprecated, updated
scripts/runqemu to use updated option instead
- added PACKAGECONFIG definitions
- added qemu-ptest to conf/distro/include/ptest-packagelists.inc
- increased support for ARM architecture, cpu and board
- removed patches merged upstream and refreshed
existing ones
Testing:
Build core-image-minimal against the machines in
openembedded-core/meta/conf/machine and succesfully
booted with qemu v5.0
Ran qemu-ptest on x86-64 and arm64 with identical results:
PASS: 1166
SKIP: 0
FAIL: 0
(From OE-Core rev: ee9ec9e344541c1ccd9b9b8e3b8c1e00d008ad85)
Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
Signed-off-by: Joe Slater <joe.slater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If libsdl is configured with opengl enabled, it will try to use GL
renderers to open a window even if qemu doesn't use virgl. Setting
the environment variable forces a software X11 renderer, which is the
same one used when libsdl has opengl switched off. This avoids
needlessly loading the GL libraries and drivers from the host.
(From OE-Core rev: 73b75f5ff6c0b5333898fa340f4d9e2e5111fdef)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Falling through to host GL stack via epoxy chrpath hack was
found to be problematic in case of SDL particularly (because it does
not actually use epoxy, and does its own dlopen()).
So let's just use the mesa-native libraries everywhere, but instruct
them to load DRI drivers from the host.
NVidia's proprietary blob users have to take care of themselves, I'm afraid.
(From OE-Core rev: 2125920828eba7bab1afc977d5e9bccb124078e5)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.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: e9b8c194636cb5505774a2a71bf54450580dd5b8)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.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>
|