linux/poky.git/meta/conf/machine/qemux86-64.conf, branch master-next

Revert "qemux86-64: Reduce tuning to core2-64"

2025-08-18T20:14:07+00:00

This was originally applied as our autobuilder had older hardware and couldn't cope with the newer settings. This has been resolved in the new cluster so we can go back to the newer tuning, which software is now more likely to need. This reverts commit 369b1dfa28b1791d45f068acc765190defecd460. (From OE-Core rev: c9585bb8689b6089ce3870910b2dbdb7e9aa547a) Signed-off-by: Richard Purdie

qemux86-64: drop duplicates with default-providers.inc

2025-06-24T12:51:31+00:00

default-providers.inc already includes PREFERRED_PROVIDER values for xserver and GL libraries. Drop the same values being set in the machine config. (From OE-Core rev: 973875c79476b70edbef8976446de1be29d50910) Signed-off-by: Dmitry Baryshkov Signed-off-by: Richard Purdie

barebox: set default BAREBOX_CONFIG for qemu machines

2024-10-11T14:57:44+00:00

These are set in the barebox class rather in the corresponding machines (where they would belong otherwise) to keep the impact of barebox to oe-core minimal for now. "multi_v7_defconfig" is used for qemuarm since this is the default barebox armv7 config that just enables all supported platforms. "multi_v8_defconfig" is used for qemuarm64 sine this is the default barebox armv8 config that just enables all supported platforms. "efi_defconfig" is used for qemux86-64 which is the primary platform where barebox will not be the first stage bootloader but an EFI payload. Since these changes make barebox a provider for virtual/bootloader, explicitly default to u-boot in the corresponding MACHINE configs to not unnecessarily surprise users. (From OE-Core rev: 93da14f8f85202bad3dec9d979d01f4e8f9708d6) Signed-off-by: Enrico Jorns Signed-off-by: Richard Purdie

qemux86-64: Reduce tuning to core2-64

2023-01-11T11:03:34+00:00

Effectively revert "qemux86-64: build for x86-64-v3 (2013 Haswell and later) rather than Core 2 from 2006" (commit 6f2af1e5d1537b4d31e14946292bf58f0fd76fc9) Much as I'd love us to use the latest tuning, we do have some autobuilder hardware which isn't ready for this yet which breaks KVM and some qemu user mode usage as there appear to be TCG bugs too. I suspect we're not the only ones with such hardware. Drop the tune back to core2-64, anyone can easily customise it themselves if they need it. We can revisit this in a year or two as we should be ready then. It has beena good test of the rest of the support which all seems ready. I'd have preferred to use corei7-64 but that causes runqemu.RunqemuTests.test_boot_machine_iso to hang. Leave the newer tune file inclusion so people can change tunes more easily. (From OE-Core rev: 369b1dfa28b1791d45f068acc765190defecd460) Signed-off-by: Richard Purdie

qemux86-64: build for x86-64-v3 (2013 Haswell and later) rather than Core 2 from 2006

2023-01-06T12:03:46+00:00

This allows us to - test those more recent instruction sets (AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE) - benefit from improved performance across the stack both in kvm-driven system emulation and when running on real silicon. For example, glibc: https://www.phoronix.com/news/Glibc-strcasecmp-AVX2-EVEX v4 level is adding AVX-512, which is far less established, particularly Intel has famously backtracked from supporting it in Alder Lake/Raport Lake client CPUs and AMD has only implemented it in very recent Zen4 products: https://www.phoronix.com/news/GCC-11-x86-64-Feature-Levels (From OE-Core rev: 6f2af1e5d1537b4d31e14946292bf58f0fd76fc9) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

qemux86-64: Allow higher tunes

2022-08-14T07:13:32+00:00

Back in 0be64e54a0e6 ("qemux86: Allow higher tunes") we moved the qemux86 machine to using the core-i7 tune file, for maximum flexibility and to allow for enabling advanced processor features if desired or required by various packagess, without changing the default tune. Do the same now for qemux86-64. Cc: Joshua Watt Cc: Richard Purdie (From OE-Core rev: a7411f5964f2e8384768b0a5e67817b3adc0ae8c) Signed-off-by: Tom Rini Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

mesa: PROVIDES virtual/libgles3

2021-12-14T22:46:38+00:00

It's assumed that not all OpenGL ES implementation are compliant with the 3.x specification. Therefore an additional virtual providers is created to explicit compatibility with OpenGL ES 3 specification. Cc: Quentin Schulz (From OE-Core rev: 405cd7a37988ced627fe6ad6fd3089c17f59367e) Signed-off-by: Quentin Schulz Signed-off-by: Richard Purdie

conf/machine: move tune files to architecture directories

2021-08-18T16:01:06+00:00

Move all of the tune files found in conf/machine/include into their respective architecture directories in that same location. All references to these will need to be updated. So, change the relevant ones for this tree in this commit as well. For the ARM tunes, nest them one further into armv8a, armv8m, etc. and rename some to make them uniform with the rest of the tunes. (From OE-Core rev: b6f15209bcfff953cce69da97a93f9ddff141ced) Signed-off-by: Jon Mason Signed-off-by: Richard Purdie

qemux86: drop resolution setting via uvesafb

2020-02-18T23:53:54+00:00

I am not sure if this has ever worked, but uvesafb is a really outdated (VBE from the 1990s), awkward (needs v86d) and limited (no support for high resolutions) way to do it. The specific reason 640x480-32 was introduced (ages ago) was to force 32 bit mode with vmware driver, as 16bit had rendering issues. The modern, supported option is video=... kernel parameter documented here: https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID https://github.com/torvalds/linux/blob/master/Documentation/fb/modedb.rst which can be passed directly to runqemu and doesn't require special kernel modules. Sato under X will continue to use 640x480 as that is hardcoded into xorg.conf under qemu. (From OE-Core rev: 1cf26f69fd89b43be24cd1232c43e5050b9d718a) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

qemu: switch to '-vga std' emulated hardware from vmware/cirrus for x86/mips

2019-09-01T21:33:07+00:00

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 Signed-off-by: Richard Purdie