KVM Host support for aarch32 to be removed in linux 5.7

[Confuzzled]

Virtualization exclusively cares about isolation of natively running code. This is neither needed by Wine nor by user-space emulation (or any other kind of ISA hardware emulation).

There are two things going on here:
1) The kernel is dropping support for KVM on arm32
Phoronix: Linux 5.7 Positioned To Retire ARM 32-bit KVM Virtualization Support Written by Michael Larabel in Arm on 16 March 2020
2) QEMU is deprecating arm32 as a host architecture
Phoronix: QEMU 5.0 Released For This Important Open-Source Emulator For Linux Virtualization Written by Michael Larabel in Virtualization on 28 April 2020

QEMU does not require kernel KVM, but being able to use it speeds things up. However, QEMU deprecating arm32 is a pain, because it means we don't have the Tiny Code Generator backend to translate TCG operations into into arm32 instructions (The front-end translates/transforms client instructions into TCG ops, the backend translates/transforms TCG ops into host architecture code, in this case arm32)

So, as I see it, QEMU no longer supporting arm32 as a host is 'worse' than loss of KVM support, as without KVM QEMU can still operate, but more slowly.

As a complete non-expert, I would have thought that the work required to maintain the QEMU TCG op to arm32 translator should be pretty well constrained, and a less fast-moving target than the mainline kernel.
QEMU Wiki: Documentation/TCG/backend-ops

So from my completely non-expert point of view, losing KVM is not fatal, as I'm not aware of a need to run arm32/Pyra as a host for multiple arm32 virtual machines* - although I acknowledge there could well be a use case, or use cases I don't know about. On the other hand, losing QEMU support for using arm32 as a host is distincly unhelpful, as QEMU is an emulator as well as a virtualizer, and it is the efficient emulation of x86/AMD64 on arm32 that we need, especially as there seems to be some form of helpful integration between WINE and QEMU, which may not be the case for WINE and Bochs.

Corrections to any errors and misunderstandings on my part above are welcome.

*Emulating one processor on another processor architecture, I think, necessitates at least a form of virtualization. I could be wrong.

 

[Letalis Sonus]

2) QEMU is deprecating arm32 as a host architecture
Phoronix: QEMU 5.0 Released For This Important Open-Source Emulator For Linux Virtualization Written by Michael Larabel in Virtualization on 28 April 2020

No it does not, it only drops support for ARM KVM guests. ARM is still available as an emulation target and host platform, because emulation is not using KVM. Read the actual changelog.

*Emulating one processor on another processor architecture, I think, necessitates at least a form of virtualization. I could be wrong.

You are wrong. Virtualization extensions only provide a level of abstraction to directly offer hardware functionality to a guest kernel without giving them the ability to influence the functionality for the host kernel. There is literally zero speed up in this for any kind of emulation, especially in user mode emulation.

 

[Confuzzled]

No it does not, it only drops support for ARM KVM guests. ARM is still available as an emulation target, because emulation is not using KVM. Read the actual changelog.


You are wrong. Virtualization extensions only provide a level of abstraction to directly offer hardware functionality to a guest kernel without giving them the ability to influence the functionality for the host kernel. There is literally zero speed up in this for any kind of emulation, especially in user mode emulation.

OK, what the changelog says is

Arm

• Support for using an AArch32 host system to run KVM guests is now deprecated (because the Linux kernel has dropped its support for this) and will be removed in a future version of QEMU. AArch32 guests on an AArch64 host are still supported.

In order to run WINE (which is not an emulator), something needs to translate the x86/AMD64 instructions of the program being run in WINE into a form that can be run on the host architecture - in our case, AArch32. QEMU does two things: it offers emulation (which requires a virtualised model of the emulated architecture), and on systems where the architecture being emulated is the same as the host architecture, it can use KVM support to mostly bypass emulation and 'simply' use the KVM implementation to provide virtualisation. This is a fast process as less instruction translation is needed (some jiggery-pokery is needed to provide the virtualisation sandbox/cage/jail)

We want to run an x86/AMD64 guest on an AArm32 host. We are not looking for ARM as an emulation target, we are looking for x86 as an emulation target hosted on AArch32, as the Pyra has an Arm32 processor.

I don't know if the documentation in the QEMU wiki is up to date, but this page has a matrix of supported hosts and guests:

QEMU Wiki: Documentation/Platforms

My reading of it is:

x86 (i386/x86-64) is a supported guest on any host (Row 5, Column TCG Guest is "Yes")
ARM (both 32-bit and 64-bit architecture) can host any supported guest with TCG generated code (Row 2, column TCG Host is "32 & 64bit")

note that i386/x86-64 emulation cannot run on multiple host threads

What I don't know, because I don't know if the Wiki is up to date, is if QEMU is dropping support for using ARM32-bit as a TCG host. You are pretty adamant that KVM is not necessary for this, but I don't know if dropping KVM support on arm32 has a consequence of also removing QEMU TCG host support. As you say, it shouldn't, but I don't know.

 

[Confuzzled]

Hmmph.

Just noticed the box86 thread.

 

[Letalis Sonus]

which requires a virtualised model of the emulated architecture

...which is entirely incompatible with the host architecture and therefore completely unable to benefit from hardware virtualization from the host. Emulation happens entirely in user space.

ARM has an entirely different MMU, an entirely different interrupt controller, an entirely different concept of exception handling and an entirely different bus system. If you are emulating an entire platform to run an OS, the OS will expect direct hardware access to hardware it knows. If you are doing user mode emulation, none of that is even needed to begin with, everything else can be achieved in a more efficient way by just using the syscalls of the host OS.

 

[levi]

I'm still not entirely sure why we need it to be honest. I wasn't aware I had any hardware capable of ring -1 virtualisation. I don't yet see why running a separate OS virtualised would in any way be faster than doing it all in one OS to be honest.

Edit: Ah, this was apparently in reply to the last post on the previous page. I'd not noticed I wasn't at the end of the thread when I wrote this. Oh well.