Posts on tony is coding

Linux 6.15, DRM scheduler, wedged events, sched_ext and more

Mon, 26 May 2025 00:00:00 +0000

The Linux 6.15 has just been released, bringing a lot of new features:

nova-core, the “base” driver for the new NVIDIA GPU driver, written in Rust. nova project will eventually replace Nouveau driver for all GSP-based GPUs.
RISC-V gained support for some extensions: BFloat16 floating-point, Zaamo, Zalrsc and ZBKB.
The fwctl subsystem has been merged. This new family of drivers acts as a transport layer between userspace and complex firmware. To understand more about its controversies and how it got merged, check out this LWN article.
Support for MacBook touch bars, both as a DRM driver and input source.
Support for Adreno 623 GPU.

As always, I suggest to have a look at the Kernel Newbies summary. Now, let’s have a look at Igalia’s contributions.

DRM wedged events

In 3D graphics APIs such Vulkan and OpenGL, there are some mechanisms that applications can rely to check if the GPU had reset (you can read more about this in the kernel documentation). However, there was no generic mechanism to inform userspace that a GPU reset has happened. This is useful because in some cases the reset affected not only the app involved in the reset, but the whole graphic stack and thus needs some action to recover, like doing a module rebind or even bus reset to recovery the hardware. For this release, we helped to add an userspace event for this, so a daemon or the compositor can listen to it and trigger some recovery measure after the GPU has reset. Read more in the kernel docs.

DRM scheduler work

In the DRM scheduler area, in preparation for the future scheduling improvements, we worked on cleaning up the code base, better separation of the internal and external interfaces, and adding formal interfaces at places where individual drivers had too much knowledge of the scheduler internals.

General GPU/DRM stack

In the wider GPU stack area we optimised the most frequent dma-fence single fence merge operation to avoid memory allocations and array sorting. This should slightly reduce the CPU utilisation with workloads which use the DRM sync objects heavily, such as the modern composited desktops using Vulkan explicit sync.

Some releases ago, we helped to enable async page flips in the atomic DRM uAPI. So far, this feature was only enabled for the primary plane. In this release, we added a mechanism for the driver to decide which plane can perform async flips. We used this to enable overlay planes to do async flips in AMDGPU driver.

We also fixed a bug in the DRM fdinfo common layer which could cause use after free after driver unbind.

Intel Xe driver improvements

On the Intel GPU specific front we worked on adding better Alderlake-P support to the new Intel Xe driver by identifying and adding missing hardware workarounds, fixed the workaround application in general and also made some other smaller improvements.

sched_ext

When developing and optimizing a sched_ext-based scheduler, it is important to understand the interactions between the BPF scheduler and the in-kernel sched_ext core. If there is a mismatch between what the BPF scheduler developer expects and how the sched_ext core actually works, such a mismatch could often be the source of bugs or performance issues.

To address such a problem, we added a mechanism to count and report the internal events of the sched_ext core. This significantly improves the visibility of subtle edge cases, which might easily slip off. So far, eight events have been added, and the events can be monitored through a BPF program, sysfs, and a tracepoint.

A few less bugs

As usual, as part of our work on diverse projects, we keep an eye on automated test results to look for potential security and stability issues in different kernel areas. We’re happy to have contributed to making this release a bit more robust by fixing bugs in memory management, network (SCTP), ext4, suspend/resume and other subsystems.

This is the complete list of Igalia’s contributions for this release:

Authored (75)

André Almeida

Angelos Oikonomopoulos

arm64: Don’t call NULL in do_compat_alignment_fixup()

Bhupesh

ext4: ignore xattrs past end

Changwoo Min

Gavin Guo

mm/huge_memory: fix dereferencing invalid pmd migration entry

Guilherme G. Piccoli

Luis Henriques

fuse: removed unused function fuse_uring_create() from header

Maíra Canal

Melissa Wen

Ricardo Cañuelo Navarro

Rodrigo Siqueira

Thadeu Lima de Souza Cascardo

Tvrtko Ursulin

Reviewed (30)

André Almeida

Christian Gmeiner

drm/sched: Use struct for drm_sched_init() params

Iago Toral Quiroga

Jose Maria Casanova Crespo

drm/v3d: Remove v3d->cpu_job

Luis Henriques

fuse: add default_request_timeout and max_request_timeout sysctls

Maíra Canal

Melissa Wen

Rodrigo Siqueira

Thadeu Lima de Souza Cascardo

scripts: add script to extract built-in firmware blobs

Tvrtko Ursulin

Tested (2)

Changwoo Min

sched_ext: Fix rq lock state in hotplug ops

Guilherme G. Piccoli

x86/split_lock: Fix the delayed detection logic

Acked (12)

Changwoo Min

Maíra Canal

drm/doc: Document KUnit expectations

Tvrtko Ursulin

Maintainer SoB (2)

Maíra Canal

drm/v3d: Add clock handling

Tvrtko Ursulin

dma-buf: add selftest for fence order after merge

Linux 6.14, an almost forgotten release

Fri, 28 Mar 2025 00:00:00 +0000

Linux 6.14 is the second release of 2025, and as usual Igalia took part on it. It’s a very normal release, except that it was release on Monday, instead of the usual Sunday release that has been going on for years now. The reason behind this? Well, quoting Linus himself:

I’d like to say that some important last-minute thing came up and delayed things.

But no. It’s just pure incompetence.

But we did not forget about it, so here’s our Linux 6.14 blog post!

A part of the development cycle for this release happened during late December, when a lot of maintainers and developers were taking their deserved breaks. As a result of this, this release contains less changes than usual as stated by LWN as the “lowest level of merge-window activity seen in years”. Nevertheless, some cool features made through this release:

NT synchronization primitives: Elizabeth Figura, from Codeweavers, is know from her work around improving Wine sync functions, like mutexes and semaphores. She was one the main collaborators behind the futex_waitv() work and now developed a virtual driver that is more compliant with the precise semantics that the NT kernel exposes. This allows Wine to behave closer to Windows without the need to create new syscalls, since this driver uses ioctl() as the front-end uAPI.
RWF_UNCACHED: Linux has two ways of dealing with storage I/O: buffered I/O (usually the preferred one) that stores data in a temporary buffer and regularly syncs the cache data with the device; and direct I/O that doesn’t use cache and always writes/reads synchronously with the storage device. Now a new mixed approach is available: uncached buffered I/O. This method is aimed to have a fast way to write or read data that will not be needed again in the short term. For reading, the device writes data in the buffer and as soon as the user finished reading the buffer, it’s cleared from the cache. For writing, as soon as userspace fills the cache, the device reads it and removes it from the cache. In this way we still have the advantage of using a fast cache but reducing the cache pressure.
amdgpu panic support: AMD developers added kernel panic support for amdgpu driver, “which displays a pretty user friendly message on the screen when a Linux kernel panic occurs” instead of just a black screen or a partial dmesg log.

As usual Kernel Newbies provides a very good summary, you should check it for more details: Linux 6.14 changelog. Now let’s jump to see what were the merged contributions by Igalia for this release!

DRM

For the DRM common infrastructure, we helped to land a standardization for DRM client memory usage reporting. Additionally, we contributed to improve and fix bugs found in drivers of AMD, Intel, Broadcom, and Vivante.

AMDGPU

For the AMD driver, we fixed bugs experienced by users of Cosmic Desktop Environment on several AMD hardware versions. One was uncovered with the introduction of overlay cursor mode, and a definition mismatch across the display driver caused a page-fault in the usage of multiple overlay planes. Another bug was related to division by zero on plane scaling. Also, we fixed regressions on VRR and MST generated by the series of changes to migrate AMD display driver from open-coded EDID handling to drm_edid struct.

Intel

For the Intel drivers, we fixed a bug in the xe GPU driver which prevented certain type of workarounds from being applied, helped with the maintainership of the i915 driver, handled external code contributions, maintained the development branch and sent several pull requests.

Raspberry Pi (V3D)

We fixed the GPU resets for the Raspberry Pi 4 as we found out to be broken as per a user bug report.

Also in the V3D driver, the active performance monitor is now properly stopped before being destroyed, addressing a potential use-after-free issue. Additionally, support for a global performance monitor has been added via a new DRM_IOCTL_V3D_PERFMON_SET_GLOBAL ioctl. This allows all jobs to share a single, globally configured perfmon, enabling more consistent performance tracking and paving the way for integration with user-space tools such as perfetto.

Your browser does not support the video tag.

A small video demo of perfetto integration with V3D

etnaviv

On the etnaviv side, fdinfo support has been implemented to expose memory usage statistics per file descriptor, enhancing observability and debugging capabilities for memory-related behavior.

sched_ext

Many BPF schedulers (e.g., scx_lavd) frequently call bpf_ktime_get_ns() for tracking tasks’ runtime properties. bpf_ktime_get_ns() eventually reads a hardware timestamp counter (TSC). However, reading a hardware TSC is not performant in some hardware platforms, degrading instructions per cycyle (IPC).

We addressed the performance problem of reading hardware TSC by leveraging the rq clock in the scheduler core, introducing a scx_bpf_now() function for BPF schedulers. Whenever the rq clock is fresh and valid, scx_bpf_now() provides the rq clock, which is already updated by the scheduler core, so it can reduce reading the hardware TSC. Using scx_bpf_now() reduces the number of reading hardware TSC by 50-80% (e.g., 76% for scx_lavd).

Assorted kernel fixes

Continuing our efforts on cleaning up kernel bugs, we provided a few fixes that address issues reported by syzbot with the goal of increasing stability and security, leveraging the fuzzing capabilities of syzkaller to bring to the surface certain bugs that are hard to notice otherwise. We’re addressing bug reports from different kernel areas, including drivers and core subsystems such as the memory manager. As part of this effort, several fixes were done for the probe path of the rtlwifi driver.

Check the complete list of Igalia’s contributions for the 6.14 release

Authored (38)

Changwoo Min

Christian Gmeiner

Luis Henriques

fuse: fix possible deadlock if rings are never initialized

Maíra Canal

Melissa Wen

Ricardo Cañuelo Navarro

Rodrigo Siqueira

Thadeu Lima de Souza Cascardo

Tvrtko Ursulin

Reviewed (36)

André Almeida

Christian Gmeiner

Iago Toral Quiroga

Jose Maria Casanova Crespo

drm/v3d: Assign job pointer to NULL before signaling the fence

Luis Henriques

Maíra Canal

Tvrtko Ursulin

Tested (2)

André Almeida

ASoC: cs35l41: Fallback to using HID for system_name if no SUB is available

Christian Gmeiner

hexagon: fix using plain integer as NULL pointer warning in cmpxchg

Acked (1)

Iago Toral Quiroga

drm/v3d: Fix miscellaneous documentation errors

Maintainer SoB (6)

Maíra Canal

Tvrtko Ursulin

Linux 6.13, I WANT A GUITAR PEDAL

Mon, 20 Jan 2025 00:00:00 +0000

Just as 2025 is starting, we got a new Linux release in mid January, tagged as 6.13. In the spirit of holidays, Linus Torvalds even announced during 6.13-rc6 that he would be building and raffling a guitar pedal for a random kernel developer!

As usual, this release comes with a pack of exciting news done by the kernel community:

This release has two important improvements for task scheduling: lazy preemption and proxy execution. The goal with lazy preemption is to find a better balance between throughput and response time. A secondary goal is being able to make it the preferred non-realtime scheduling policy for most cases. Tasks that really need a reschedule in a hurry will use the older TIF_NEED_RESCHED flag. A preliminary work for proxy execution was merged, which will let us avoid priority-inversion scenarios when using real time tasks with deadline scheduling, for use cases such as Android.
New important Rust abstractions arrived, such as VFS data structures and interfaces, and also abstractions for misc devices.
Lightweight guard pages: guard pages are used to raise a fatal signal when accessed. This feature had the drawback of having a heavy performance impact, but in this new release the flag MADV_GUARD_INSTALL was added for the madvise() syscall, offering a lightweight way to guard pages.

To know more about the community improvements, check out the summary made by Kernel Newbies.

Now let’s highlight the contributions made by Igalians for this release.

Case-insensitive support for tmpfs

Case sensitivity has been a traditional difference between Linux distros and MS Windows, with the most popular filesystems been in opposite sides: while ext4 is case sensitive, NTFS is case insensitive. This difference proved to be challenging when Windows apps, mainly games, started to be a common use case for Linux distros (thanks to Wine!). For instance, games running through Steam’s Proton would expect that the path assets/player.png and assets/PLAYER.PNG would point to be the same file, but this is not the case in ext4. To avoid doing workarounds in userspace, ext4 has support for casefolding since Linux 5.2.

Now, tmpfs joins the group of filesystems with case-insensitive support. This is particularly useful for running games inside containers, like the combination of Wine + Flatpak. In such scenarios, the container shares a subset of the host filesystem with the application, mounting it using tmpfs. To keep the filesystem consistent, with the same expectations of the host filesystem about the mounted one, if the host filesystem is case-insensitive we can do the same thing for the container filesystem too. You can read more about the use case in the patchset cover letter.

While the container frameworks implement proper support for this feature, you can play with it and try it yourself:

$ mount -t tmpfs -o casefold fs_name /mytmpfs
$ cd /mytmpfs # case-sensitive by default, we still need to enable it
$ mkdir a
$ touch a; touch A
$ ls
A  a
$ mkdir B; cd b
cd: The directory 'b' does not exist
$ # now let's create a case-insensitive dir
$ mkdir case_dir
$ chattr +F case_dir
$ cd case_dir
$ touch a; touch A
$ ls
a
$ mkdir B; cd b
$ pwd
$ /home/user/mytmpfs/case_dir/B

V3D Super Pages support

As part of Igalia’s effort for enhancing the graphics stack for Raspberry Pi, the V3D DRM driver now has support for Super Pages, improving performance and making memory usage more efficient for Raspberry Pi 4 and 5. Using Linux 6.13, the driver will enable the MMU to allocate not only the default 4KB pages, but also 64KB “Big Pages” and 1MB “Super Pages”.

To measure the difference that Super Pages made to the performance, a series of benchmarks where used, and the highlights are:

+8.36% of FPS boost for Warzone 2100 in RPi4
+3.62% of FPS boost for Quake 2 in RPi5
10% time reduction for the Mesa CI job v3dv-rpi5-vk-full:arm64
Aether SX2 emulator is more fluid to play

You can read a detailed post about this, with all benchmark results, in Maíra’s blog post, including a super cool PlayStation 2 emulation showcase!

New `transparent_hugepage_shmem=` command-line parameter

Igalia contributed new kernel command-line parameters to improve the configuration of multi-size Transparent Huge Pages (mTHP) for shmem. These parameters, transparent_hugepage_shmem= and thp_shmem=, enable more flexible and fine-grained control over the allocation of huge pages when using shmem.

The transparent_hugepage_shmem= parameter allows users to set a global default huge page allocation policy for the internal shmem mount. This is particularly valuable for DRM GPU drivers. Just as CPU architectures, GPUs can also take advantage of huge pages, but this is possible only if DRM GEM objects are backed by huge pages.

Since GEM uses shmem to allocate anonymous pageable memory, having control over the default huge page allocation policy allows for the exploration of huge pages use on GPUs that rely on GEM objects backed by shmem.

In addition, the thp_shmem= parameter provides fine-grained control over the default huge page allocation policy for specific huge page sizes.

By configuring page sizes and policies of huge-page allocations for the internal shmem mount, these changes complement the V3D Super Pages feature, as we can now tailor the size of the huge pages to the needs of our GPUs.

DRM and AMDGPU improvements

As usual in Linux releases, this one collects a list of improvements made by our team in DRM and AMDGPU driver from the last cycle.

Cosmic (the desktop environment behind Pop! OS) users discovered some bugs in the AMD display driver regarding the handling of overlay planes. These issues were pre-existing and came to light with the introduction of cursor overlay mode. They were causing page faults and divide errors. We debugged the issue together with reporters and proposed a set of solutions that were ultimately accepted by AMD developers in time for this release.

In addition, we worked with AMD developers to migrate the driver-specific handling of EDID data to the DRM common code, using drm_edid opaque objects to avoid handling raw EDID data. The first phase was incorporated and allowed the inclusion of new functionality to get EDID from ACPI. However, some dependencies between the AMD the Linux-dependent and OS-agnostic components were left to be resolved in next iterations. It means that next steps will focus on removing the legacy way of handling this data.

Also in the AMD driver, we fixed one out of bounds memory write, fixed one warning on a boot regression and exposed special GPU memory pools via the fdinfo common DRM framework.

In the DRM scheduler code, we added some missing locking, removed a couple of re-lock cycles for slightly reduced command submission overheads and clarified the internal documentation.

In the common dma-fence code, we fixed one memory leak on the failure path and one significant runtime memory leak caused by incorrect merging of fences. The latter was found by the community and was manifesting itself as a system out of memory condition after a few hours of gameplay.

sched_ext

The sched_ext landed in kernel 6.12 to enable the efficient development of BPF-based custom schedulers. During the 6.13 development cycle, the sched_ext community has made efforts to harden the code to make it more reliable and clean up the BPF APIs and documentation for clarity.

Igalia has contributed to hardening the sched_ext core code. We fixed the incorrect use of the scheduler run queue lock, especially during initializing and finalizing the BPF scheduler. Also, we fixed the missing RCU lock protections when the sched_core selects a proper CPU for a task. Without these fixes, the sched_ext core, in the worst case, could crash or raise a kernel oops message.

Other Contributions & Fixes

syzkaller, a kernel fuzzer, has been an important instrument to find kernel bugs. With the help of KASAN, a memory error detector, and syzbot, numerous such bugs have been reported and fixed.

Igalians have contributed to such fixes around a lot of subsystems (like media, network, etc), helping reduce the number of open bugs.

Check the complete list of Igalia’s contributions for the 6.13 release

Authored (70)

André Almeida

Changwoo Min

Christian Gmeiner

drm/v3d: Use v3d_perfmon_find()

Guilherme G. Piccoli

Maíra Canal

Melissa Wen

Thadeu Lima de Souza Cascardo

Tvrtko Ursulin

Reviewed (41)

André Almeida

Christian Gmeiner

Iago Toral Quiroga

Jose Maria Casanova Crespo

drm/v3d: Ensure job pointer is set to NULL after job completion

Juan A. Suarez

drm/vc4: Use vc4_perfmon_find()

Maíra Canal

Tvrtko Ursulin

Tested (1)

Christian Gmeiner

drm/etnaviv: Replace the ‘&pdev->dev’ with ‘dev’

Acked (5)

Changwoo Min

Maíra Canal

Maintainer SoB (6)

Maíra Canal

Installing kernel modules faster with multithread XZ

Fri, 03 Mar 2023 00:00:00 +0000

As a kernel developer, everyday I need to compile and install custom kernels, and any improvement in this workflow means to be more productive. While installing my fresh compiled modules, I noticed that it would be stuck in amdgpu compression for some time:

XZ      /usr/lib/modules/6.2.0-tonyk/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko.xz

XZ format

My target machine is the Steam Deck, that uses .xz for compressing the modules. Giving that we want gamers to be able to install as many games as possible, the OS shouldn’t waste much disk space. amdgpu, when compiled with debug symbols can use a good hunk of space. Here’s the comparison of disk size of the module uncompressed, and then with .zst and .xz compression:

360M amdgpu.ko
61M  amdgpu.ko.zst
38M  amdgpu.ko.xz

This more compact module comes with a cost: more CPU time for compression.

Multithread compression

When I opened htop, I saw that only a lonely thread was doing the hard work to compress amdgpu, even that compression is a task easily parallelizable. I then hacked scripts/Makefile.modinst so XZ would use as many threads as possible, with the option -T0. In my main build machine, modules_install was running 4 times faster!

# before the patch
$ time make modules_install -j16
Executed in  100.08 secs

# after the patch
$ time make  modules_install -j16
Executed in   28.60 secs

Then, I submitted a patch to make this default for everyone: [PATCH] kbuild: modinst: Enable multithread xz compression

However, as Masahiro Yamada noticed, we shouldn’t be spawning numerous threads in the build system without the user request. Until today we specify manually how many threads we should run with make -jX.

Hopefully, Nathan Chancellor suggested that the same results can be achieved using XZ_OPT=-T0, so we still can benefit from this without the patch. I experimented with different -TX and -jY values, but in my notebook the most efficient values were X = Y = nproc. You can check some results bellow:

$ make modules_install
174.83 secs

$ make modules_install -j8
100.55 secs

$ make modules_install XZ_OPT=-T0
81.51 secs

$ make modules_install -j8 XZ_OPT=-T0
53.22 sec

futex2 at Linux Plumbers Conference 2022

Fri, 23 Sep 2022 00:00:00 +0000

In-person conferences are finally back! After two years of remote conferences, the kernel development community got together in Dublin, Ireland, to discuss current problems that need collaboration to be solved.

As in the past editions, I took the opportunity to discuss about futex2, a project I’m deeply involved in. futex2 is a project to solve issues found in the current futex interface. This years’ session was about NUMA awaress of futex. Currently, futex allocates a single hash table in the kernel to store all data. If this is done in a NUMA machine, the table is allocated in a single node. This increases the cost of futex operations when done from any other node, given that will need to access a memory outside of it’s node.

To solve this, futex2 will allocate a table per NUMA node and have a NUMA-aware interface to tell the kernel which node to work on, using this struct:

struct futexX_numa {
   __uX value;
   __sX hint;
};

Where X can be a range of values [8, 16, 32, 64], for each available futex size in futex2. value is the futex value and hint is the node where you want to operate on. It can be -1 for the current node or [0, MAX_NUMNODES) to specify the node. So, for example:

struct futex32_numa f = {.value = 0, .hint = -1};

futex_wait(&f, 0, FUTEX_NUMA | FUTEX_32, NULL);

The session was short, but very productive, with Peter Zijlstra and Thomas Gleixner giving most feedback about the proposal. Here’s a list of ideas that were covered in the session and are to be consider when implementing this interface:

Userspace always initialize .hint = -1. The kernel then overwrites -1 with the current node being used by the first waiter. In that way, every following futex operation (wait or wake) will be guaranteed to be on the same node.
After the last waiter is waked, .hint can be set as -1 again.
To avoid racing, any change to the struct futex_numa needs to be done atomically for the whole structure.
The struct needs to have explicitly alignment and to be __packed.
Benchmark data will for sure attracts reviewers and users. perf bench is the right place to add that.
The local hash table doesn’t need to be as big as is the global futex table, probably num_possible_cpus() will be enough.
Support for a struct futex64_numa might be tricky, so we might just restrict for smaller sizes. hint may be always s16 giving that MAX_NUMNODES isn’t that huge.

Here are my slides from this year. If you need any help with futex, you can get in touch with me andrealmeid@igalia.com.

Apart from futex, there were other talks to highlight. As a trend in recent Plumber editions, Rust was once again a hot topic in the conference. From a single session at LPC 2020, this year we had Rust in the main track, in the Maintainers Summit and its own Microconference. The initial mistrust of adding a second language to the kernel is long gone, and now the conversations are around the final bits on how to get it merged (Will the patches go though the maintainers tree, or directly to Torvalds? Which Rust version to use? Stable or unstable?). This whole effort is a good showcase of the conference ability to join efforts from different companies, communities and projects along the stack (GCC, clang) to solve complex problems together. Oh, and if you are wondering, Rust will likely be available in Linux 6.1 or 6.2.

From the GPU world we had a session to discuss how to deal with accelerator drivers in the kernel, as there’s some disagreement on how to accept (and where to accept) these new drivers. Along with that, a BoF to talk about getting a userspace console to be used in case the graphics stack crashes and how to get an implementation of cgroups for GPUs.

The Kernel Testing & Dependability Microconference was a stage to get news from testing tools, like syzbot, kselftests, KernelCI and KUnit. There was some discussion on how to integrate all frameworks as well, given that there’s a lot of testing nowadays, but not much communication and deploying of all this. Last but not least, Tales Aparecida (my GSoC mentee) presented the challenges of using KUnit to test device drivers.

That’s it for 2022 edition. Thanks Igalia for sponsoring my travel to LPC and see ya next year!

Keeping a project bisectable

Thu, 04 Aug 2022 00:00:00 +0000

People write code. Test coverage is never enough. Some angry contributor will disable the CI. And we all write bugs.

But that’s OK, it part of the job. Programming is hard and sometimes we may miss a corner case, forget that numbers overflow and all other strange things that computers can do.

One easy thing that we can do to help the poor developer that needs to find what changed in the code that stopped their printer to work properly, is to keep the project bisectable.

A “bisectable” project is a project where one can reliably run git bisect, which is a very useful command to find a commit that introduces a bug. It works doing a binary search in the git history until finding the guilty commit. This process involves building each step of the bisect and running a test on each build to check if it’s good or bad (that you can magically automate with git bisect run). The problem is, if you can’t compile, you can’t tell if this commit is before or after the bug (it can even be the culpable commit itself!). Then you need to jump and try another commit and hope that it will compile, making the process more painful. A lot of build breakages along the commit history can easily discourage a brave bisecter.

Keep it buildable

To make sure we keep the bisectability of a project, we just need to make sure that every commit is buildable. Sometimes we split a feature in a bunch of cool commits but fail to see if they work as standalone changes. We can simply do a interactive rebase, building it at each step:

git rebase -i main --exec "make"

Replace main with the reference that you want to build from and make with your fancy build system and ta-da, let the magic happen. If any of the steps fails to build, the rebase stops (given that “any command that fails will interrupt the rebase, with exit code 1”) so you can investigate what happened.

Of course, there’s still some room for build breakages for different build configurations, but if you always follow this practice before upstreaming your patches you are building a better git log.

Discussion on Reddit.
Discussion on Hacker News

Resurrecting a bootlooped Nexus 5X

Mon, 23 Nov 2020 00:00:00 +0000

Nexus 5X (also know as bullhead) was launched in 2015, manufactured by LG and designed by Google, and is the successor of Nexus 5. Even today, this device has some nice features like its 12.3 MP Rear camera, fingerprint sensor, USB C and a hexa-core ARM CPU. However, this last item was controversial: issues during the manufacturing process could lead to a problem in the CPU soldering, resulting in an infinite cycle of reboots, called Bootloop of Death (or just BLOD).

In this post, I’m going to show how I managed to overcome this issue (besides some story behind it) and install a fresh LineageOS 17.1 with MicroG.

As anything that you read in the internet, I can’t assure that this will solve your problem. I’ve written this in the in the best of intentions, but I’m not responsible for the destruction of devices, data, friendships or environments that you may cause by following my guide.

The Bootloop of Death

N5X has an heterogeneous 64-bit ARMv8-A CPU: four 1.4 GHz Cortex-A53 cores and two 1.8 GHz Cortex-A57 cores. This architecture, named as big.LITTE, was developed to have a nice balance of energy and performance: during a heavy load, the task scheduler will give the work to the two big cores, decreasing the latency for the end-user, for the price of higher energy use. In the meanwhile, the kernel will just use the four little cores, saving some battery.

However, between 2015 and 2016, someone took a wrong decision in a LG business meeting and a lot of devices got manufacturing defects, (e.g. G3, G4, G5, G7, V10, V20) including the Nexus 5X. The problem in bullhead was in the CPU assembling, where a bad soldering makes the big cores separated from the motherboard and unreachable by the operating system¹. Then, seeing that something had failed, the system would reboot in the hope that things get better. And will go like that, again and again.

Basic diagram of how the topology looks like in my mind

Shut up and give my money

LG acknowledged the issue and replaced the motherboard of affected devices, extended warranty and returned the money for some angry consumers. However, in some corner cases, for instance, if you purchased the device while traveling abroad, if LG believed the device was exposed to moisture, if you lost the deadline for taking an action, or just found this old mobile in some forgotten drawer, you may have a BLOD affected device lying around. It’s too late to ask LG for help, but it’s not the end.

Break the loop

(Do not) Burn your cellphone

In order to make the device bootable again, we need an unlocked bootloader. If you already have one, just continue to next section.

Before doing that, we need to enable USB Debugging in the system’s settings. But, in order to do that, you need to turn on your device and properly boot it, something that the bug prevents us to do in the first place.

Caution: this is where things start going dangerous. You have been warned.

The internet is made of some brave and curious people. Someone out there discovered a temporary fix that makes the device bootable and operating: point a heat blower to the device, near the camera for some minutes. The problem is that it’s a temporary fix, and it makes the cellphone work only for a few minutes as well. This would make the solder reach temperatures near the melting point, slightly making everything in contact again for a short period of time. This should give you enough time to enable everything you need for breaking the loop. Since I don’t have a heat gun, I just used a common hair dryer and I can say that it worked! Start heating and testing, paying attention for not to burn your device. Also, those temperature variations could make things worse, so I’m not quite sure about how many attempts you have available.

Hot n Cold: u/Deconceptualist and u/subenvarg0 in Reddit said that the following also did the trick for booting the device: “Put the phone in a ziploc, then leave it in the freezer for 30 minutes.” It seems that “the cold contracted the housing or components enough to make the motherboard and big cores connect temporarily”. I tried that, but it didn’t work for me, just the hot version.

Once you managed to boot the device, you need to quickly enable debugging options. From the LineageOS wiki, this can be done in some simple steps using the phone:

Open Settings, and select “About”.
Tap on “Build number” seven times.
Go back, and select “Developer options”.
Enable “OEM unlock” option.
Scroll down, and check the “Android debugging” or “USB debugging” entry under “Debugging”.

Make big.LITTLE just LITTLE

The worst part of our quest is done now, so it’s time to disable some cores. The bootloader begins the initialization of the system using the little cluster, and then tries to get the big cluster ready, and here is where the problem lives. The fix for it is quite simple: just a sort of sysfs and kernel parameter modifications that disable the big cluster. If there’s no cluster to fail, the loop will not happen.

The following steps require a computer with some Android tools installed (adb and fastboot). I have tested in a GNU/Linux distribution, but it should work good in different OS’s as well.

Unlocking bootloader

First of all, we need to unlock the bootloader. Here are the steps, as described in LineageOS wiki:

Enter in fastboot mode by pressing Volume Down + Power while the device is powered off.
Connect the device to your computer via USB.
Once the device is in fastboot mode, verify if your computer finds it by typing (you will likely need sudo):

fastboot devices

Now type the following command to unlock the bootloader:

fastboot flashing unlock

Follow the instructions that appears on the screen and wait for the reboot.

Custom recovery

Now we need a customized custom recovery, that supports bullhead and uses only 4 cores. You can find one here, look for the twrp-3.2.1-0-fbe-4core-bullhead.img one.

Back to the fastboot mode, use this command to flash the custom recovery:

fastboot flash recovery

For stock ROM fans

If you’re happy with the stock ROM (the last version officially supported is Android 8.1), there’s a guide that fix BLOD for that ROM from XDA: [TOOL][HOW-TO] [Nexus 5X] Bootloop of Death (BLOD) Workaround². I haven’t tested myself, but if it works, congratulations! Your device is now ready to be used again. However, if you want a more updated experience, stay tuned.

Installing things

Now, I’ll proceed to create an almost degoogled system, using LineageOS 17.1 (Android 10) and MicroG. I ain’t getting in details about what is what, but here are a few handful links:

Learn more about LineageOS here
Learn more about MicroG project here

LineageOS

There’s no official LineageOS image for this device, just images independently developed by someone in the community. In my experience, those ROMs have equally quality, so the unofficial status is not a big deal. theandroid02 is one of such developers, and for your convenience, has patched the image with the BLOD fix, so you can just flash it without more hacks.

You can download the ROM at XDA forums.

Get back to your device in flashboot mode, and boot on recovery.

Starting by wiping the device, both “Normal” and “Format data” mode (if by some miracle you haven’t lost your data yet, you will lost it for sure here).
Go in Advanced menu and enable ABD Sideload. This method will copy the zip to the device and install it. To flash it, run

adb sideload <path-to-lineage-17.1-bullhead.zip>

When I was trying to do that, the device would complain something about error E3004 and the installation would fail. I believe that this is due to a bug in the recovery image that I’m using. Here is what happens: in the installation script of the ROM, the first line does a small sanity check, comparing if the device is compatible with the ROM (i.e. is this a bullhead device?). This check is very useful and I’m sure it saved some precious devices out there. However, the recovery image and the install script can’t come to terms and agree that they are both for a bullhead device. So I just removed the first line of META-INF/com/google/android/updater-script:

assert(getprop("ro.product.device") == "bullhead" || getprop("ro.build.product") == "bullhead" || abort("E3004: This package is for device: bullhead; this device is " + getprop("ro.product.device") + "."););

Now, try again. It should work this time.

If you want to install core Google apps (Play, Service, etc) now is the time to do so. Download your favorite package for Android 10 and ARM64 here and install it using the sideload method described earlier. If you do so, the tutorial ends here: go enjoy your device!

My clean LineageOS lock and home screen

The “Open” at “Open GApps” is about the scripts and the infrastructure created by the community on how to install proprietary software from Google. For installing open source alternatives for the later, keep reading.

MicroG and friends

In order to make MicroG work properly, we need to enable signature spoofing³, so MicroG will pretend to be Google Services + Play Store and apps will work as expected (at least, most of times). The first step for doing so is installing Magisk, a “suite of open source tools for customizing Android”. I installed version 20.4 and it worked fine. Use the adb sideload method to install it and boot your phone.

Open Magisk, go to Download and search for the following modules: Riru Core and Riru EdXposed. Those modules will help us to modify the behaviour of apps. You will also need to install EdXposed Manager. A pop up should appear notifying that, but you can also download it here.

Open EdXposed Manager and install the module fakegapps, finally allowing signature spoofing. You need to manually enable it inside EdXposed. Boot the system in recovery again. Now, it’s time to install MicroG.

FriendlyNeighborhoodShane developed a nice zip containing all the software you need to use MicroG. I downloaded the NoGoolag-2.7 version at GitHub. To learn more about the difference of releases, check out the README.

Boot the device once more, and open the MicroG self test, in MicroG settings. Everything should be marked and looking good there. A lot of apps are really not that useful without Push Notifications, so you may want to enable it at “Device registration” and “Google Cloud Messaging”. There’s an app called Push Notification Tester that you can download from Aurora Store (the alternative to Google Play) and check if it’s working as expected. If it’s not, try dialing *#*#2432546#*#* and rebooting one last time. It might take some minutes (and some reboots) in order to start working, so be patient.

Bonus: Google Camera

You may have heard about Google Pixel series and how its camera is very impressive. While some manufactures need to use two or three cameras to get the same quality for a picture, Google achieves similar results using artificial intelligence tricks, like taking a lot of frames and merging the best ones.

However, this is not widely available for all devices. First, the hardware needs to support some functions like raw capture and ISO control, and the Android version needs to export those functionalities. In order to support all those features, the phone needs to have API Camera2 Level3 and you can use this app to check the support on your device: Camera2 API Probe. Spoiler: Nexus 5X has full support. What is left to use the app? It seems that Google doesn’t use the normal Android API, they are doing some stuff that makes the application hard to port for other devices… what is something different on the Android ecosystems, where you usually write the app once and it works everywhere.

Someone did the hard work for us and ported it to Nexus 5X. You can download it at Chromloop and check the thread at XDA. I must say that the app didn’t worked in my setup. Maybe is MicroG, maybe is LineageOS 17.1, I don’t know for sure. If you ever made it work for you, please share with me what have you done. There is a huge repo of unofficial Google camera ports maintained by Celso Azevedo. I tried a few, and none have worked.

What did worked, however, is the Go edition, a simplified version that doesn’t make the best from the hardware but it does some basic tricks. I downloaded it here. It’s up to you to test them and find out what takes good pics.

Final words

The Bootloop of Death as seeing in a microscope

This work would be impossible without the huge effort from random folks around the internet. All the links that I used to create this guide are scattered in this post. Thanks for getting here and for the courage that takes to bring to life a five years old device.

Discussion on Reddit.
Discussion on Hacker News

This problem is similar to what happened in the first generation of Xbox 360, where the incorrect type of soldering leads to cracks in high temperatures. ↩︎
This link also has a lot of good information about the problem. Read it carefully if my guide doesn’t help you. ↩︎
Free Software Foundation Europe wrote a cool article explaining what is signature spoofing in the context of Android. ↩︎

Flash LineageOS 17 + microG on a Nexus 5

Thu, 05 Nov 2020 00:00:00 +0000

In this tutorial, I’m going to show how I installed LineageOS 17.1 with disk encryption and microG in my Nexus 5.

hammerhead

Nexus 5 is an old phone. It was launched in October 2013 (designed by Google, manufactured by LG), but differently than some 2013 phones, it still works! Even in 2020, I’ve used it as daily driver and it works quite well for my use case. All peripherals still works, I can use 5GHz Wi-Fi and 4G mobile data (it even supports wireless charging!). The battery life can carry on for one complete day. The quality of photos is not as good as current phones, the device isn’t super fast for some tasks and I needed to replace the battery once, but overall it is enough for basic messaging and internet browsing.

However, even if works fine, the vendor doesn’t provide official support anymore and was discontinued in march 2015. The initial Android version was 4.4 “KitKat”, it got updates until Android 6.0.1 “Marshmallow” in December 2015, with a lifetime of a bit more than 2 years.

It got a good reception, as was one of the most balanced products in terms of price and performance, along with the robustness and well made. The first release got some problems like battery life and an unstable camera, however, those problems got better on following Android releases.

GSMArena collects information about the hardware and also have some comments and reviews from users, like those:

JMac: My girlfriend uses my old Nexus 5 and I was surprised to find the other day that it can get a 4G signal. Don’t think we had 4G in 2013.

Alphadurus: Unbelievable how so many users still using nexus 5 in 2020, I got mine replaced 3 years back.. Nexus 5 was a beast for sure but widt poor battery. I got 2 hours sot max. But it was the best phone for rooting and adding modded os.. still the king of good times..

sajith: I’m using my nexus 5 from July 2014. This is one of the best mobile phones I have ever used. Still no lags.

In XDA Developers forum, is possible to see that the community around this device has tons of ROMs, posts and comments. The process of flashing a ROM can take some minutes but it’s very straightforward, so I invite you to browse XDA and try some ROMs for you to find out what fits your purpose. I won’t be explaining each piece of the stack in the tutorial, but here are some helpful links:

Learn more about LineageOS here
Learn more about MicroG project here

The tutorial

DISCLAIMER: inserting a new operation system in your phone shouldn’t make it unusable forever (also know as bricking), but it could. Steps described here worked fine in my device and I did my best to be as descriptive as possible, but unfortunately I can’t assure that will work in all cases. Only proceed following the commands only if you are comfortable with the procedure.

I’m using GNU/Linux for this tutorial. Make sure you have adb and fastboot installed in your system. In Arch Linux, this can be found in the package android-tools.

Unlocking the bootloader

Your device comes with a bootloader that is locked by default, so you can’t flash any new cool ROMs as it is. However, the unlocking procedure is no trouble. This is a common pattern for devices from Google, and it’s very helpful. Some vendors can make this procedure very hard, and some can be even impossible! Instructions from LineageOS wiki:

First step, boot in your current ROM and go to settings.
Tap 5 times in the “Build number” to enable developers options.
Go to developers option and enable USB debug. Connects the device to a computer using a USB cable.
Boot to the bootloader:
- Shut the device down, and press Volume Down + Power
- Or, run $ adb reboot bootloader in your computer.
Check if the computer detects the device:
- sudo fastboot devices
Unlock the bootloader. Notice that this step will remove the warranty, but you don’t have one anymore right?:
- sudo fastboot oem unlock
A screen with options will appear. Use the volume buttons to select YES and press power to confirm. If the device does not reboot, reboot it.

Flash a custom recovery

Nexus 5 has a recovery mode that allows us to wipe data from a device and to factory reset it. Using a custom one gives us more powerful options, like flashing a new ROM. The most famous custom recovery project is maintained by Team Win Recovery Project (TWRP) and trusted by the community.

For this device specifically, we are going to use a slightly different one. It’s a fork that comes with a small tool that increases the size of system/ partition and decreases the cache/ one. This is done because the stock partitioning scheme is too small for current Android/LOS images.

You can download it from XDA, and it also provides some useful information about the tool.

After downloading it, go to phone’s bootloader and flash the recovery:

fastboot flash recovery <recovery_filename>.img

Now, boot to the recovery mode using the bootloader menu.

Wipe the old system using the Wipe menu. First, tap Format Data. After that is completed, get back to Wipe menu, select Advanced Wipe, after that select the Cache and System partitions and then Swipe to Wipe.

Repart the filesystem

Go to Advanced menu and select Terminal. Use the following command to resize it:

hh_repart -m

Wait until it reboots.

Install LineageOS

There are tons of ROMs around XDA for Nexus 5. The flash process is basically the same for all them, so I recommend you to check out some ROMs and find which one is better. I chose the unofficial release of LineageOS 17.1 and you can download it in XDA. Then, in recovery mode, select Advanced and ADB Sideload. On host machine, run:

sudo adb sideload <lineage-17.1-file.zip>

With this step, LineageOS is installed on the mobile.

Encryption

If you want to use disk encryption (something I highly recommend), you need to perform some extra steps before using it. These are the steps I did in order to make it work:

Boot in system. again.
Setup a password or lock pattern. You can change the pattern matrix from 3x3 to up to 6x6.
Go to Settings > Security and click in the “Cryptography” option.
Wait until it’s finished, and we are done!

If your device doesn’t want to boot, you can try those steps (without losing the encryption):

After it gets completed, get back to recovery.
In Settings, mark the option use rm -f instead of formating.
Get in Wipe and mark Data in Advanced Wipe.
Get back to the system. The phone should be encrypted and ready to be used.

MicroG and friends

In order to make MicroG work properly, we need to enable signature spoofing¹, so MicroG will pretend to be Google Services + Play Store and apps will work as expected (at least, most of times). The first step for doing so is installing Magisk, a “suite of open source tools for customizing Android”. I installed version 20.4 and it worked fine. Use the adb sideload method to install it and boot your phone.

Open Magisk, go to Download and search for the following modules: Riru Core and Riru EdXposed. Those modules will help us to modify the behaviour of apps. You will also need to install EdXposed Manager. A pop up should appear notifying that, but you can also download it here.

Open EdXposed Manager and install the module fakegapps, finally allowing signature spoofing. You need to manually enable it inside EdXposed. Boot the system in recovery again. Now, it’s time to install MicroG.

Conclusion

Thank you for recycling a device, the planet says thanks. However, if LineageOS hackers get tired of it and none release new ROMs, it might be time to search for another mobile… or use postmarketOS.

Discussion on Reddit.
Discussion on Hacker News.

Free Software Foundation Europe wrote a cool article explaining what is signature spoofing in the context of Android. ↩︎

How to use Hammer Editor in Linux

Thu, 28 May 2020 00:00:00 +0000

Talk is cheap, show me the code: TL;DR

One key part of Valve games is the ability to create custom user content. The Source SDK, with the Hammer Editor and the in-game developer console (with a crazy amount of commands) have allowed the community to create tons of contents, including maps and new game modes, that eventually leaded to games like Counter Strike, Portal and Garry’s Mod.

This tutorial will focus on how to create new maps for Counter Strike: Global Offensive using the Hammer Editor in Linux.

To get started, I’m assuming that you already have a functional GS:GO game installed and working on your Linux machine. I’ve tried this with AMD GPUs and Intel Integrated Graphics. If you have problems running in NVIDIA, try using a staging version of Wine. Also, I’m using ArchLinux with the most recent Proton, kernel and Mesa to date of writing (May of 2020). As the stack evolves, the steps described here are subject to change in the future.

Crafting the hammer

Downloading some steel

There is no native release of Hammer, so we need to use the Windows version. To get it, install the “Counter Strike: Global Offensive - SDK” from your library, in the “Tools” section. Not everyone is able to access the tool however: one needs to either had purchased the game when it was paid, or had bought the Prime Status Upgrade. If you get Prime by playing the game, you still need to buy the status to download the SDK. This is done probably to restrict low quality items to be sent to the workshop, requiring an investment from wannabe mappers.

The tool has some sort of integration with the game files, and expects the Windows version of the game. To get those files, one could download the Windows version of the game from Steam library, but there’s a more clever way to do so, using the Steam console, a command line interface to manage Steam library. To open it, copy and paste steam://open/console in your web browser or run steam -console on your terminal. A new tab “CONSOLE” will appear right side of your profile tab. Finally run download_depot 730 732 to download the Windows files. This command will download, from game 730 (CS:GO), depot number 732 (Windows binaries).

Steam console

Moving parts

Go to your Steam local folder (cd ~/.steam/steam). The files that you just downloaded will be found at ubuntu12_32/steamapps/content/app_730/depot_732/, and we just need to copy then to the CS:GO folder. ubuntu12_32 will be your folder independently of your distro, since this is how Steam Runtime deals with their libraries. If everything works fine, you can deleted the app_730 folder later:

cp -r ubuntu12_32/steamapps/content/app_730/depot_732/* "steamapps/common/Counter-Strike Global Offensive"

Hammering some nails

This should be enough to open and run the editor. Just click “Launch” in your library and a nice menu from 90’s should appear. Double click the Hammer option and after some seconds the tool will appear.

Let’s create a simple map to test our game. Use the block tool (Shift + B) to make a big cube. It needs to be big enough to fit a player model, more than 192 units of height will be more that enough. For reference, the player camera has 64 units of height. After making it with the proper size, press enter to create the cube. Use “Tools > Make Hollow” to create a border for the map. With the Entity tool (Shift + E), place a spawn point for the player (info_player_terrorist) somewhere inside the cube.

Too complex? I have create a map for you with this all done, download here and open with Hammer. Save a copy in the default folder:

~/.steam/steam/steamapps/common/Counter-Strike\ Global\ Offensive/sdk_content/maps/

To compile the map, press F9 and leave the options BSP, VIS and RAD with “Normal”. Select HDR for RAD, “Don’t run the game after compiling” and “Wait for keypress when done compiling”. Press OK and let the magic happen.

Compile menu

If everything works fine, let’s test it. As far as I know, we can’t open the game from the tool, since it will try to open the Windows version in the Windows way. The workaround is fairly easy. Open your native version of the game, and open the console. If you never opened it before, go to “Settings > Game Settings > Enable Developer Console: Yes". Now hit the ` key (grave) to open it. Run map de_test, and your custom map will open. Congratulations! Now go there and create Dust III.

de_test in action

Expert options

If you want to use the “Expert” compilation options (and you want to do that for calculating the light of your objects), you will find trouble in the first time. This happens because in Windows the tool works fine if you use the name of the map’s file without the extension .vmf, but this will not work in Wine. To fix that, just check the parameters for $bsp_exe, $vis_exe, $light_exe and search for $file. This is the source file of the map that you are editing, and just edit the parameters from $file to $file.vmf after that variable and you should be good. It is not needed to edit the Copy File options since it already has the file extension. I didn’t edit the option $game_exe since I wasn’t able to run the game from the tool anyway.

Expert options menu

Dealing with leaks

If your map has leaks, it means it has problems that makes it impossible to compile. Your map should be a closed box, without any opening to the external world, otherwise the compiler will not be sure what is “inside” and what is “outside” of the map. If you don’t place any spawn point, the tool will not compile the map as well. The BSP step will fail, and it will warn you in the console output and won’t generate a .prt file.

In Windows, the VIS step will nicely notify the user that the file wasn’t found, but at Wine we get a page fault probably due to some behavior that doesn’t exactly matches the way Windows does. If the compiler fails with a long list of memory addresses and fails, check the file <map_name>.log in the same folder you saved the map and search for “leaked”. You can also run just the BSP step of compilation, since is when the maps is checked for leaks. After a leak is found, a file is created to show the holes in your map. Use “Map > Load Pointfile” to open it.

A beautiful page fault

Native port?

Valve is by far one of the companies that invests the most for the Linux gaming scene, mainly driven by development of Proton and their high quality native games, so is natural to believe that there is a chance that Valve could release a port of the tool for Linux. However, when people in Valve’s GitHub project asked for a native port, kisak pointed to this comment:

Hammer relies heavily on AFX/MFC which are windows only libraries. You’d have to essentially rewrite the tool to get it working on non-Windows operating systems.

AFX/MFC stands for “Application Framework Extensions” and “Microsoft Foundation Class Library” that, as you may guess, are Windows-only libraries. Valve would then need to rewrite all the tool backend to get it native, or implement an emulation layer for those libraries, just as Proton does, so I don’t think we will see a native port of Hammer itself, but maybe we will have more lucky someday if we have a new editor around.

Bugs in Wine

Sometimes applications in Proton/Wine don’t behave exactly like in Windows, and this is a bug. There are some undocumented behaviors that Wine relies on to run properly. For instance, in the case of this bug, it could be about some uninitialized variable or use after free. Then, Wine needs to implement the buggy in order to correctly run Windows applications. This also happened when .NET team at Microsoft ported the old C# compiler from C++ to C#:

Writing a new compiler for C# means trying to match the old compiler bug-for-bug. And I’m not just talking about known bugs, but those unknown and unintended behaviors that developers have found and come to rely on, often unknowingly.

Conclusion

I haven’t tested all aspects of the tool, but I could compile and run some simple maps made by my friends and some maps from the examples files. I didn’t try to use any of texture creating tools (VTEX and VFTEdit), but since Hammer and its build chain are far more complex than them, I believe it won’t be hard. If you found major bugs running the Hammer Editor through Proton, the best place to comment is in the issue tracker of the tool on GitHub, where I found the workaround I used to create this post. Thanks for the users Erik Bročko and Eoin O’Neill for the initial research in this topic and for sharing it in GitHub.

I opened de_inferno.vmf to see how the tool performed with a more complex and finished map, and it’s the pre-2016 version of the map. The tool was a bit lag when navigating the 3D preview of the map, like if it wasn’t using hardware acceleration. The compilation took some minutes as it was doing the hard work using only one thread. When finally completed, the map was working as expected.

As I said before, compiling with basic options won’t give you proper lighting and color for some objects, you will need the “expert” options to use the $light_exe that will give you a normal map.

de_inferno with basic compiling options

de_inferno with “expert” compiling options

More resources

Since the goal of this post is about getting the tool running, rather than using it, here are some recommendations of resources about that:

TL;DR

Run this in Steam console:

download_depot 730 732

Then in your terminal:

cd ~/.steam/steam && cp -r ubuntu12_32/steamapps/content/app_730/depot_732/* "steamapps/common/Counter-Strike Global Offensive"

Append .vmf at all $files without any extesion in expert options. The tool will be ready to open and work. Beware leaks in the map. Save the map in the default folder (~/.steam/steam/steamapps/common/Counter-Strike Global Offensive/sdk_content/maps/). Open the Linux version of CS:GO, type in console map <map_name> and have fun.

Thanks to lcagustini, chinen93 and leandrohrb for reviewing and testing this tutorial!

Discussion on Reddit.
Discussion on Hacker News.

Finally, how to flash AMD VBIOS in Linux

Fri, 01 May 2020 00:00:00 +0000

Check my previous post to know more about the background of this story.

After publishing my rant on the web about the lack of a native GNU/Linux application to flash my the VBIOS of my AMD card, it turns out that the Linux version was in a public repository in GitHub. Simple like that.

Downloading

You can get the tool on GitHub (check the commit log for older versions) or get from AUR: amdvbflash.

Using

Every option of amdvbflash requires administrative privileges, so use sudo to run it. To get all options, just run the tool without arguments:

$ sudo amdvbflash
AMDVBFLASH version 4.69, Copyright (c) 2020 Advanced Micro Devices, Inc.

--- amdvbflash v4.69 ---
-h, -?, /h, /?          Help (this screen)
...

Use -i to list all cards in the system:

$ sudo amdvbflash -i

adapter seg  bn dn dID       asic           flash      romsize test    bios p/n
======= ==== == == ==== =============== ============== ======= ==== ================
   0    0000 03 00 731F Navi10          GD25Q80C        100000 pass 113-EXT900170-L07

Back up current image with -s <Num> <File> [Size] (recommend before flashing):

$ sudo amdvbflash -s 0 bios.rom

0x100000 bytes saved, checksum = 0x7CE5

Gather details of a VBIOS image file using -biosfileinfo <File>:

$ sudo amdvbflash -biosfileinfo bios.rom

    Product Name is :    NAVI10 A1/A2 D18901 XLE 6GB 300e/750m
    Device ID is    :    731F
    Bios Version    :    017.001.000.049.900170
    Bios P/N is     :    113-EXT900170-L07
    Bios SSID       :    5120
    Bios SVID       :    1849
    Bios Date is    :    01/17/20 01:27

Finally, to flash your card with an image, use -p <Num> <File>:

$ sudo amdvbflash -p 0 bios.rom

The software does a sign check using a public key from AMD, so it will only flash “trusted” images. You can test the signature with -rsa <filename> option. Keep in mind that this verification is done solely in software, so it can be bypassed using binary hacking.

As noted by u/nikomo , bypassing this check is not a good idea:

AMD GPUs starting from Vega GPUs check the signature and refuse to start if it doesn’t validate.

Thanks Patrick for sharing the tool with me!

Discussion on Reddit.
Discussion on Hacker News.

That day when I tried to flash my AMD VBIOS in Linux

Fri, 10 Apr 2020 00:00:00 +0000

Prologue

It’s 2019. AMD is more than ready to take its place in the GPU market share. Right after the release of RX 5600 XT, AMD and manufacturers partners released an update for the VBIOS (yes, GPUs also have BIOS) changing the clocks of processors making the card even more powerful.

The selection of graphics drivers for AMD hardware is comparibly very good. AMD is contributing to upstream projects like the mainline kernel code base and Mesa. And even maintaining their own projects like amdvlk or Compressonator.

There are 3 different Vulkan implementation available for Linux, which all use the amdgpu kernel module.

AMDGPU Pro, the proprietary userspace AMD Vulkan implementation.
amdvlk, an new open source Vulkan implementation by AMD.
radv, the free Vulkan implementation for AMD maintained by the Mesa project.

In addition you also can use a OpenGL 4.5 conformant GL implementation RadeonSI from Mesa, implemented on the Gallium framework.

radv also recently gained a new shader compiler ACO, which was sponsored by Valve. It is delivering considarable performance improvements compared to the old one.

Let’s do it

So here I’m, just one more GNU/Linux user with my GPU properly installed and running just fine. Oh wait, it seems that I can upgrade its VBIOS in order to improve performance, it shouldn’t be that hard, right? Right?

Since this is the first time I do such operation, I started with some DuckDuckGoing to check the required steps. Each manufacturer (e.g. Gigabyte, ASRock, etc) is responsible to providing the update software for theirs users. Some lucky people managed to get an updated board from factory, while some versions won’t get support for the new version at all.

Since I’m not lucky, I need to flash my card. My model is the “Radeon RX 5600 XT Challenger D 6G OC”, also know as “RX5600XT CLD 6GO”. If you open the model page and click in the support tab, there’s one button named “vBIOS”. Clicking it reveals this text box:

The detailed description “Enhance performance.” quickly gets my attention and I know that I’m where I need to be. But calm down, let’s read all the information.

Please read the information below before downloading or updating your vBIOS

Sure, safety first.

We do not recommend users to update the vBIOS if their graphics card is already running normally.

Wait. So it seems that ASRock released a software to enhance performance of the card, but asks you not to do so and tells you that actually this is not a good idea.

ASRock assumes no responsibility for any damages caused by improper operations of downloading or updating the vBIOS.

And if something went wrong, good luck dealing with that.

Before you download or update the vBIOS, please read “(How to Update)” below carefully.

In the column “Update vBIOS Under/ How to Update” there’s only one entry where is possible to read Windows. These are bad news for me, since I have no Windows around to use. I click anyway in search for more knowledge and (as suggested) I carefully read the four steps instructions on how to extract a compressed file and how to double-click in a batch file, but they are all for Windows, so wasn’t so useful for me. Anyway, I click and download the “Global” option just in case I need it in the future.

The zip contains two files: Update.cmd and h566GCLDO_L07_X64Gop_2_09.exe. The first one is basically a batch script that call the second one with update as argument. The second one seems to be a C++ application to flash the card. It is important to notice that this binary is a Windows application with a VBIOS image embedded. To get only the image, TechPowerUp hosts a collection of VBIOS images. If an appropriated flashing tool. My first attempt failed, now it’s time to search again.

amdmeminfo

Looking for some kind of software to hack my AMD GPU that run in Linux, I discovered that there is one called amdmeminfo. Mysteriously, there was no entry at ArchLinux User Repository.I moved forward and decided to give a try. For that, I choose the first GitHub result in DDG, hoping for the best and that should be the most relevant one. From the README, we can read that “Get GDDR5 memory information and other information from AMD Radeon GPUs.” Not bad, huh?

After following the build instructions, I managed to get my binary. This was the result of the first run:

AMDMemInfo by Zuikkis <zuikkis@gmail.com> Updated by Yann St.Arnaud
<ystarnaud@gmail.com> 03:00.0: Unable to unlock vbios
“./amdmeminfo” terminated by signal SIGSEGV (Address boundary error)

After reading the code, I realized that this segfault had occurred because this version of the tool doesn’t support my card and no one checked if (gpu == NULL). I need a more recent version of amdmeminfo for my card. The “original” repo, the one ystarnaud has chosen to fork from Zuikkis isn’t modified since 2014, so I think it will not help me. Back to the repo I’m using, there is a Pull Request. Maybe it’s to add to support RX 5600 XT, who knows?

add files via upload

No description provided.

Files changed 1: BIN +385 KB xmrig-proxy-master.zip

Well, you don’t need to be a git expert to see that’s something going strange here. I download the file and opened, and it’s an entire different repo download as zip, to deal with alt-coins proxy: xmrig-proxy.

Not sure what were VIP21’s intentions with this move, but it doesn’t seem it was succeeded. I moved to check the forks, and found that there are 50 ones, mostly from cryptomining people. After checking one by one, minershive’s (also a cryptocoin enthusiastic account) one seems to be the most reasonable one, with support to RX 5600 XT! It stills segfault, but at least was able to output the current version of my vBIOS:

113-EXT900162-L05

When I discovered this software, there were 50 forks. Now we have 51 forks!

Standars, by xkcd

I had renamed the tool to amdgpuinfo, since we get more general information about a GPU, not only about memory (at least for my card, I can’t get any memory information for now). You can find my repo at my GitLab. I also solved the problem with AUR package, and created one: amdgpuinfo-git. This tool was useful only to get my VBIOS version, since it can’t flash the card (at least for now).

atiflash / amdvbflash

As I continued my seek for Linux tools that could flash AMD cards, I found a lot of tutorials on how to do it in Windows. One popular tool among those guides is called atiflash, a tool to manipulate AMD GPUs and their VBIOSs. ATI was a company acquired by AMD and become part of the GPU development sector, but since 2010, the name ATI name isn’t used in any products released by them. So even with this outdated name, this tool shows some potential.

FreeDOS

I first heard of it in this guide in TechPowerUp’s forum, teaching how to use atiflash to flash your VBIOS. Wait, FreeDOS?

It seems like a lot of Windows users don’t trust it to perform such critical actions as flashing your VBIOS GPU. An unexpected interruption, reboot, a spiked CPU load or blue screen could corrupt the image and brick the card. Windows Update, Windows Defender, Cortana, antivirus, virus, all those softwares could work together to do that for you.

So how do you use your flashing tool, a Windows binary, in a safe environment? The answer got me by surprise, but if you are familiar with this kind of procedures, you probably already know FreeDOS. This is a GPL DOS-compatible operating system that allows you to run Windows software in an isolated condition. No updates, no voice assistance. Hopefully, no internet either. Just you and a command prompt, waiting for your order. Fortunately, Windows has a good retro compatible ABI, meaning that you can run some simple software in any release between from DOS to Windows 10.

Supported OS: Linux

The version of atiflash that is used in this guide, v4.17, is able to work on DOS as I tested in FreeDOS. But won’t be even nicer just using this in GNU/Linux? I could only find one version of this software for my OS, in a shady repository from konqueror1, one more cryptominer: https://github.com/konqueror1/atiflash. This tool, as version 4.25, could not detect my flash card, so I needed a more updated one. Just to be sure, I tried in FreeDOS. It worked fine, but it couldn’t detect my card as well.

Hopefully, the same TechPowerUp website hosts atiflash versions, along with VBIOS images, so maybe it was just a matter of finding the right version, with the right image. So I grab the 2.93 version for download, but it only has Windows versions. Changelog says that in August 15th, 2019, support for flashing Navi Radeon RX 5700 Series BIOS was added. Two important things to notice here: even that this release is newer, it’s version has a lower number than the one that we found before (4.15). Also, the name of binary is actualy “AMDVbFlash”, without “ATI” anymore. Probably they reset the version counter when changing the name, but kept the old name in pages to enhance the Google visibility. Once again I fire my FreeDOS USB, but this time all I get from the tool is “This Program Can not Be Run in DOS Mode”. It turns that this message is bultin in the software, and it seems that it just print this and then exits, if it is running in a DOS environment. Maybe some developer in AMD changed the compiler or build system, breaking the DOS compatibility on the way.

We had already tested Linux and DOS versions out there, but TPU doesn’t provide any of then. In the hope that another tech forum has some binaries for me, I found more two websites: Guru3D and Geeks3D. I have no idea if they same some kind of relation or just use similar names by chance. By just a few days of difference, both pages posted the 3.04 release of the tool:

Geeks3D post comes with a promise that I was waiting for:

Supported OS:
- Microsoft Windows (32bit/64bit)
- UEFI
- Linux
- DOS

My hope quickly ended, when clicking for download I was presented to AMDVbFlash_v3.04.exe file. Extracting the .exe, there is an EndUserLicenseAgreement(use).doc by AMD and a readme.txt. Once again, the README states that Linux, UEFI and DOS are all supported, along with a nice AMD Copyright.

Screwed Drivers

Those tools should be coming from somewhere, hopefully from AMD itself, since they are both developer and copyright owner of the tool. However, the only mention that I could find about the tool in AMD website is in their security page.

Screwed Drivers

8/11/19

At AMD, security is a top priority. We were made aware of the public disclosure of potential industry-wide, driver-related vulnerabilities on August 11, 2019 and, after gaining new information from the researcher, AMD now believes this is related to a disclosure communicated to us earlier this year regarding the AMDVBFlash graphics driver tool that was temporarily made available on our website so early adopters of older AMD graphics products could perform a needed Video BIOS refresh and has since been removed. AMD is continuing to investigate the issue to determine if any other of our drivers may be affected.

To learn more about how this was being exploited, you can read the post by the researchers at Eclypsium’s blog:

Drivers that provide access to system BIOS or system components for the purposes of updating firmware, running diagnostics, or customizing options on the component can allow attackers to turn the very tools used to manage a system into powerful threats that can escalate privileges and persist invisibly on the host.

In summary, attackers could flash vulnerable firmware and driver to escalate privilege to read/write in kernel space. The article talks only about Windows, so it doesn’t seem to affect Linux. Also, it’s not clear about the role of “AMDVBFlash” in that attack, the article only says that “[…] the very drivers and tools that would be used to update the firmware are themselves vulnerable and provide a potential avenue for attack.”. To prevent users exploiting this attack, they removed the tool from their website, although they can’t delete it from the internet. It would be nice to have a fixed version for users, or even the source code, so they could fix it themselves. I just hope that they didn’t take down the tool with the argument that “it could be used to flash malicious images”. Similarly, this would be like removing the web browser, since it could be used to download malware.

Geeks, Gurus and miners

As you may have noticed, this statement was announced in August 8th, but the TechPowerUp and Geeks3D/Guru3D released versions after that date, in January 24th. It would make sense that this tool continues under development for AMD and their manufacturers partners, and there might have someone inside AMD leaking this software for those forums. The first line of the changelog is “AMDVBFLASH EXTERNAL – WINDOWS”, that once again brings more questions than answers. Is there an internal version? Is there a non-Windows binary? How did {Geek,Guru}3D managed to get access to this release, even after AMD saying that the tool was removed from their website?

I also found a Linux version of this tool in “ethOS Mining OS”, a paid distro for mining coins that offers atiflash as a cool feature and in “minerstat” distro as well. However, after reading their documentation, I strongly believe that this version is the old ATIflash v4.25 that I tried before.

Given all that, I couldn’t find a single tool to flash my card without a running Windows machine. The poor user amd762 even posted in AMD community forum, asking for a Linux version for the tool, but got only the silence.

That day when I tried to flash my AMD VBIOS in LinuxWindows

AMDVBFlash in graphical mode, running in Windows 10

Eventually, I gave up, took the road and after 100 kilometers I reached the house of a friend of mine that have a Windows machine. We opened the cabinet, replaced the GPU, opened Windows 10 and fired up those tools described during the article. First, I did a backup of the current VBIOS image with AMDVbFlash and then used the ASRock solution to install the new one. Fortunately, all worked fine and my card now has a faster clock.

In more recent news

Luckily, now the situation is slight better in Linux side. After I did all those steps to get my VBIOS updated, I found the following resources:

Overclocking in Linux

There is a post in Reddit that teaches you how to change the voltage and frequency of your AMD card. This is basically an overclocking, but as far as I know, the performance result should be the same as flashing the VBIOS. Read the comments, since there are some useful tips and information there.

AMDVBFlash, UEFI version

TechPowerUp surprises me again, and release an UEFI shell version of AMDVBFlash 2.93 out of nowhere. Technically, this should be the best way to flash you card, since it doesn’t depend on your OS, just requires that you have a motherboard that supports UEFI. Just copy the files in a pen drive formated as FAT32 and boot it.

This release wasn’t made by AMD itself, but by “W1zzard”, an administrator from TechPowerUp. I’m not sure if it’s a reverse engineer of the original tool, or it’s the UEFI version released by AMD but with the Copyright modified. I couldn’t find more information about this developer, since their Twitter account has just one tweet with “6.5 million LinkedIn passwords” in a pastebin.

I tested following commands and everything worked as expected:

Listing devices/adapters: amdvbflash -i

Write the VBIOS of adapter 0 at file: amdvbflash -s 0 <file>
Check VBIOS info in a given file: amdvbflash -biosfileinfo <file>

Note: after I published this post, W1zzard commented in Reddit clarifying the situation:

W1zzard from tpu here, the uefi flasher itself is amd original, i packaged it into a simple download with uefi shell and wrote the uefi Scripts

We’re not hosting the newer vbflash because it requires that driver which has security issues as you mentioned. The current 2.93 can flash all amd cards so no reason to use the newer version and jump through the driver hoops

Also, the UEFI version tool can be found with some vendors images, as is the case of MSI image.

Conclusion

AMD, in contrast with others GPU vendors, does a great job supporting Linux drivers in upstream. However, it lacks support for a VBIOS flashing tool in Linux (despite their confusing README stating the opposite), so RX 5600 XT users need to do wild things to get their card updated, including using Windows. If the tool was open source, I’m very confident that the community would support a Linux release. Thanks for reading, and if you know something about what is going on, I would love to hear.

Check my next post to see the final outcome of this history.

Thanks Lubosz for joining me in this adventure, digging in the web, looking for software, inspiring and reviewing this text.

Discussion on Reddit.
Discussion on Hacker News.

Create an ArchLinux image for kernel testing

Tue, 10 Mar 2020 00:00:00 +0000

In this tutorial, we’ll look on how to create a functional and simple ArchLinux virtual machine image, that can access the internet, display graphical windows and share a folder with the host to help you with your kernel development. The only requirement is that you need to have a working ArchLinux installation.

A virtual machine is useful in a lot of development scenarios, but it’s particularly essential in the Linux kernel development. It can be really time-consuming to install the kernel on your own system and then needing to reboot the machine just to see if your printk() is working. This is why this topic was already covered in Collabora’s blog, with Ezequiel explaining how to use virtme and Frédéric showing how to setup a minimal Debian to use with QEMU-KVM.

As already said by my colleagues, there’s no need to install a complete system from scratch, using a installation disc. If you’ve already used to Arch Linux, you probably know that the distro slogan is “Keep it Simple, Stupid”. So let’s try not to suffer in order to get a kernel development environment. It may seem to be complicated to achieve this, but once I explain all the concepts behind it, you will notice how this is very customizable and easily scriptable, so you can automate this part of your workflow.

Since we’re going to work with two systems at the same time, let’s explicitly state in which machine you should run the command:

(host)$ # for you real machine

(guest)$ # for the virtual machine

Creating a disk

We will need a disk to store our new OS in. Hopefully, we have no need for a physical device, a file will do the work. It’s up to you how much space you’ll allocate, but I recommend a minimum of 4 GB. We’re going to create a 5GB sparse file (a file that allocates space as needed) to be our disk, using the truncate command:

(host)$ truncate -s 5G arch_disk.raw

If you check the size with du -h arch_disk.raw, it’s going to say 0 (because we haven’t used it yet), but if you run du -h --apparent-size arch_disk.raw you can see the maximum size the file may expand.

Let’s add a file system at this file. This means that this file will be ready to contain files and folders, and will contain the new file system as its data. This will make our disk to look and behave as a single partition.

(host)$ mkfs.ext4 arch_disk.raw

Since we have a file that represents a partition, we can mount it. Create a directory to be the mounting point and mount it:

(host)$ mkdir mnt
(host)$ sudo mount arch_disk.raw mnt

Installing ArchLinux

Now that we have a disk, let’s place an initial system, just like when we are installing Arch. Install these packages:

(host)$ sudo pacman -S arch-install-scripts qemu

The first package has some scripts that are really helpful to install ArchLinux (e.g. pacstrap, arch-chroot) and the second one is the QEMU emulator.

Just remember to check if you are using a nice mirror close to you on top of your mirrorlist file (/etc/pacman.d/mirrorlist). This will speedup your download.

Now, let’s transform that formatted partition into a functional system. pacstrap is wrapper for pacman that will install in the first argument (mnt) the packages/groups (base, base-devel) and create the root filesystem, with the appropriated folders (lib, dev, tmp, home, …). You may also take this step to add more packages that you would like to have in the virtual environment, like vim for instance. If you want to enable internet access in the guest in the future, use this step to install the dhcpcd package. Just add then after base-devel in the following command:

(host)$ sudo pacstrap mnt base base-devel

Pro tip: if your host system is up-to-date, you can use the flag -c to just copy the packages from your host to the guest, instead of downloading them all again: pacstrap -c mnt ...

This will create the directory structure and install the basic packages. You can navigate through mnt/ and see an entire file system there, and even change the root to this new system:

(host)$ sudo arch-chroot mnt

If you use ls and pwd you will see that you are definitely in a guest system, and not in your host machine anymore. If you use uname -r you can see the kernel version was installed on your host system:

(guest)$ ls
bin   dev  home  lib64	     mnt  proc	run   srv  tmp	var
boot etc  lib	 lost+found  opt  root	sbin  sys  usr
(guest)$ ls home/
(guest)$ pwd
/
(guest)$ uname -r 4.20.7-arch1-1-ARCH

Once inside, it can be useful to set a password for the root user with passwd.

Use CTRL+D to exit from the guest and then sudo umount mnt to umount the disk. Let’s use a custom kernel now.

Using QEMU and your kernel

Now, for the next steps, you will need a compiled and functional Linux Kernel. You already have one, since you are running a GNU/Linux distribution, but if you still don’t have a custom kernel to make experiments, you can easily get one like this:

(host)$ git clone --depth=1 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
(host)$ cd linux
(host)$ make x86_64_defconfig
(host)$ make kvm_guest.config
(host)$ make -j8

The goal of this article is not get in details on how to compile the kernel. For more information, check the Arch wiki article and have a look at ccache.

The git command will clone Linus’ tree source code of the kernel into your machine. With the argument --depth=1, you won’t clone all the commit history of the kernel and the download will be faster. If you want to have the history (which is advisable with you want to send patches to the project), remove this argument. The make ...config commands will create a basic kernel with virtualization powers for x86_64 machines.

make -j8 can take some time and some CPU usage. The -j8 argument will create 8 jobs to compile the kernel, change it according to the number of threads in your machine.

Let’s play with QEMU. We are going to use a lot of flags and arguments, so let’s check in details each one:

-hda disk.raw: specify that the arch_disk.raw file should be provided as the first hard disk in the emulated system.
-m 4G: amount of RAM we are going to loan to the virtual machine.
-nographic: QEMU will run on the terminal instead of a graphical window.
-kernel linux/arch/x86_64/boot/bzImage: define the file where your compressed kernel image is. You can also use the kernel installed on your machine, it should be somewhere in /boot/.
-smp 1: how many virtual CPUs QEMU will use.
-append "root=/dev/sda rw console=ttyS0 loglevel=5": kernel parameters.
- root defines which disk/partition has the root file system. In our case, it will be the first storage device¹, the hard disk arch_disk.raw.
- rw that we want to read and write to disk.
- console is to set the standard output of the kernel and of the PID 1.
- loglevel is to set how much log the kernel will output to the console and 7 is the highest and it will display all the kernel messages in the console prompt.
  - I don’t find the Audit logs useful. You can disable them with audit=0.
  - You can learn more about kernel parameters in the documentation;
--enable-kvm: this is to enable hardware acceleration to virtualization.

Feel free to change these parameters to suit your environment. Now run it all together:

(host)$ qemu-system-x86_64 -hda arch_disk.raw -m 4G -nographic \
        -kernel linux/.../bzImage \
        -append "root=/dev/sda rw console=ttyS0 loglevel=5" \
        --enable-kvm

When the prompt displays archlinux login:, just type root and enter. Use uname -r again to check which kernel you are running. When you are done, use CTRL+a then x to exit:

archlinux login: root
(guest)$ uname -r
5.0.0-rc1+

If you always use the root user, you may set to auto login using systemd. Type systemctl edit serial-getty@.service in the guest and a text editor will open. Add those lines and in the next login you should be good:

[Service]
ExecStart=
ExecStart=-/usr/bin/agetty --autologin root --noclear %I $TERM

Connecting to the internet

You may want to install some packages on your virtual machine or perform some network tests, but as it stands, you can’t reach the internet:

(guest)$ ping eff.org
ping: eff.org: Temporary failure in name resolution

Let’s use our host as a network bridge; login in our virtual machine with root user and then:

(guest)$ systemctl enable dhcpcd
(guest)$ systemctl start dhcpcd

Every time your system boots, it’ll start to run a DHCP service and connects to the internet using a “virtual wire” to the host.

(guest)$ ping eff.org
PING eff.org (173.239.79.196) 56(84) bytes of data.

Due to the configuration of the NAT, you won’t get ping answers like 64 bytes from vm1.eff.org (173.239.79.196): icmp_seq=1 ttl=46 time=197 ms. However, since we managed to solve the DNS (since ping showed to us the IP address of eff.org), we are sure that we have internet connection.

Displaying graphical windows

If you want to run graphical applications inside your virtual machine, you may follow one of the methods:

QEMU display: use QEMU display in graphical mode with a GUI compositor;
SSH with XForwarding: use your own terminal to SSH into the VM and then display the content using your host’s display.

This can be useful to test some subsystems like DRM or V4L2. Keep in mind that the performance won’t be the best and the functionality can be a bit buggy, so I recommend using lightweight apps like gstreamer and ffmpeg.

QEMU display

The first difference here is that we’re going to remove the -nographic argument from QEMU. Run it now and it should open a new window.

Now, make sure to have this module enabled at your kernel: DRM_BOCHS, a driver to help us displaying graphical content in QEMU. This means that if you open the .config file at your kernel source directory it should have this line: CONFIG_DRM_BOCHS=y. Remember to recompile the kernel each time you change it’s configuration.

We need software to manage the windows and display them on the screen, so we are going to install a lightweight Wayland compositor, weston:

(guest)$ pacman -S weston xorg-server-xwayland xorg-fonts-type1 xorg-xclock

Create a file ~/.config/weston.ini in guest and add this:

[core] xwayland=true

Run the weston command in guest, and the graphical interface should appear. You can use your mouse to open the weston-terminal at the top left corner. If your mouse is moving oddly, make sure your window zoom is set to the “Best fit” option in the QEMU window bar. Inside the terminal, run xclock and you should be able to check the hours inside your virtual machine. When you’re done, you can use Ctrl+Alt+Backspace to quit weston.

Screen capture showing xclock inside weston

This is just the basic setup using QEMU graphical mode. To improve performance and usability (like to have clipboard and multimonitor support) one can use a QEMU front end (like virt-manager) or SPICE to expand your options and features between guest and host. Check the ArchWiki to learn more about virtual graphic cards, graphics acceleration and SPICE.

XForwarding

This is a way to display graphical interfaces running in a remote host in the local machine. This means that the X server on your guest machine will forward the graphical input/output to the X client on your host machine. You can keep the argument -nographic in QEMU. Let’s get some packages that will help us (you need to install xorg-auth in both machines, the host and guest):

(host)$ sudo pacman -S xorg-xauth

(guest)$ pacman -S xorg-xauth xorg-xclock openssh xorg-fonts-type1

As in the last section, our goal here is to run the application xclock, a simple graphical clock as a proof of concept. If you try to run it now, this should happen:

(guest)$ xclock Error: Can't open display:

That’s why we are going to use SSH, to help us get the graphical output. The default TCP port of SSH is 22, but probably your localhost already has reserved this port. Besides this, the IP address QEMU gives to your VM usually isn’t routable. So, let’s map our guest 22 to another port, let’s say 1337, and expose this port using the hostfwd option. This can be done with these additional QEMU flags:

-net nic: creates a basic network card;
-net user,hostfwd=tcp::1337-:22: maps port host’s 1337 to guest’s 22.

If you try to access the machine now via ssh (with QEMU running with this new parameters), it won’t be possible yet:

(host)$ ssh root@localhost -p 1337 ssh_exchange_identification: read: Connection
reset by peer

In the guest, if you run systemctl status sshd, you can see that it isn’t running. Let’s configure sshd before running it. Let’s edit guest’s /etc/ssh/sshd_config to ensure that you have those lines uncommented and edited:

PermitRootLogin yes # allows root login with password via ssh
X11Forwarding yes # allows XForwarding

Let’s configure sshd to run at boot and to start now:

(guest)$ systemctl enable sshd
(guest)$ systemctl start sshd
(guest)$ systemctl status sshd
* sshd.service - OpenSSH Daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
     Active: active (running)
     ...

To have access to the guest without using a password every time, you can place your SSH public key inside the file ~/.ssh/authorized_keys. You can copy and paste your key in this file while the guest machine is running, or you can mount the guest rootfs and write in the file, like this:

(guest)$ # Stop guest machine using CTRL+A, X
(host)$ sudo mount arch_disk.raw mnt
(host)$ sudo su
(root-host)$ cat /home/user/.ssh/id_rsa.pub > mnt/root/.ssh/authorized_keys
(root-host)$ exit
(host)$ sudo umount mnt

Start the virtual machine again and, with a second terminal session, try to login:

(host)$ ssh root@localhost -p 1337
Last login: Mon Feb 18 17:57:15 2019 from 10.0.2.2
(guest)$

You can use exit command to close the session. If you don’t have a .Xauthority file on your home folder, it will prompt a warning, but don’t worry: after the warning, the file will be created. Access the virtual machine using ssh with the argument -X:

(host)$ ssh -X root@localhost -p 1337

And check the hours with xclock! To exit, you can also use CTRL+D.

Screen capture showing xclock with XForwarding

Shared folder between host and guest

Copy-pasting is definitely not the best way to send a file to your guest machine. Hopefully, we can easily solve this problem by sharing a folder between machines.

If you ran make x86_64_defconfig and make kvmconfig before the kernel compilation, you should already have the required modules enabled. If you get errors, please make sure your kernel has the following options enabled:

(host)$ grep 'VIRTIO_PCI=\|NET_9P=\|9P_FS=\|NET_9P_V\|IG_PCI=' .config
CONFIG_NET_9P=y
CONFIG_NET_9P_VIRTIO=y
CONFIG_PCI=y
CONFIG_VIRTIO_PCI=y
CONFIG_9P_FS=y

If something looks like # CONFIG_XXX is not set, you should enable it.

Now, elect a folder to be your shared holder, for example /home/user/shared. Then, we need to add more arguments to our QEMU command:

-fsdev local,id=fs1,path=/home/user/shared,security_model=none: this will add a new file system device to our emulation. Make sure to put the right directory at path. Don’t worry about security_model=none, this argument will let the permission of creating/modifying files inside the guest as if was created by the host user.
-device virtio-9p-pci,fsdev=fs1,mount_tag=shared_folder: this defines the name and type of the virtual device.

We need to edit our guest /etc/fstab. It should look like this:

# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
shared_folder /root/host_folder 9p trans=virtio 0 0

This determines the mounting pointing of the shared folder. As long you are consistent, you can choose whatever name for shared_folder and host_folder. Reboot the guest machine and then:

(guest)$ ls /root/
host_folder

Adding a new user

For some testing or actions, it’s maybe useful to have a regular user, that is not the root one. For instance, makepkg refuses to run as root for safety reasons. The following commands should be used in the guest. Use useradd -m user -G wheel to create a new user with the name user, with a home directory and part of group wheel. You can set a password for it using passwd user. To use this account, just type su user. If you want to login to this user from SSH, remember to add the public key to /home/user/.ssh/authorized_keys. If you want to be able to run any sudo command without typing password, run as root user visudo and uncomment the line that says %wheel ALL=(ALL) NOPASSWD: ALL.

Conclusion

You may also want your kernel to have a custom name, it may be useful for you to organize your versions. You can do this changing the LOCALVERSION value at menuconfig or simply running make LOCALVERSION=, e.g.:

(host)$ make LOCALVERSION=-VM ...
(host)$ qemu-system-x86_64 ...
(guest)$ uname -r
5.0.0-rc1-VM

Now you can easily hack and test your kernel! I recommend you read this section of the ArchWiki, as you’ll find some cool tips to improve your VM performance. You may also want to create scripts and alias to not deal with all the flags, that will definitively make your life easier.

This content was originally posted at Collabora’s blog , as part of my Software Engineer job. It was slight updated and edited before being posted here.

The observant will notice that the argument used by QEMU to specify the first drive is hda, which results in the kernel enumerating a drive as sda. Historically IDE drives were labelled hdX (where X is an increasing drive letter), but for quite a while it has been typical for IDE drives to be accessed via an emulation layer in the SCSI subsystem, which labels drive sdX. Also in contrast to how most physical hard drives are used, we have not created a boot partition and partitions in the virtual drive, instead treating the whole device as a partition, and thus lacking the numerical suffix we would typically see when referring to specific partitions. ↩︎