KVM Host support for aarch32 to be removed in linux 5.7


ingoreis

Advanced Member
Staff member
Joined
Jan 18, 2010
Messages
8,095
Age
39
Location
49.491276,8.423518
Do that mean someone can compile now a Qemu with KVM Acceleration for our Pandora?
KVM Acceleration would be a realy nice Speedup in Qemu for Windows95 and others.

maybe @notaz or @ptitSeb can compile this with Acceleration for us?
 

lukey

Rare Species
Joined
Jun 17, 2015
Messages
493
Location
Germany
No, KVM support for aarch32 will be *removed*. That means we won't be able to use the KVM acceleration in the Pyra anymore.
 

Linux-SWAT

Hardcore Member
Joined
Feb 13, 2010
Messages
8,509
I guess many people will be upset, so either it's undone, either there will be a community patch.
It's not that useful, but it's a juicy feature.

BTW, it's only for ARM 32 bit hosts to support accelerated ARM 32 bit guests.

Shame.
But on the other hand, will we benefit so much from newer Kernel?
It's always good to be on the latest kernel, especially when @hns is working on it :^) .
 

Silent-Hunter

Hardcore Member
Joined
May 29, 2010
Messages
3,148
I was planning to use KVM for exactly that, I think we should stick with a kernel version that supports it until it can be merged back in.
 

Silent-Hunter

Hardcore Member
Joined
May 29, 2010
Messages
3,148
I think the Pyra will at least double the number of people using or wanting to use KVM on aarch32.
 

Confuzzled

Member
Joined
Oct 1, 2018
Messages
57
Does it prevent using WINE? My plan is/was to run a particular niche (old) Windows application on the Pyra. The program happily runs on WINE in x86/AMD64 land. My understanding was that you could configure QEMU in User Space Emulation mode - out of date link/howto here: https://github.com/AlbrechtL/RPi-QEMU-x86-wine. If KVM on aarch32 is gone, along with WINE support, I suspect that makes life difficult.

Or am I going to have to look at using Bochs?
 

Confuzzled

Member
Joined
Oct 1, 2018
Messages
57
The "V" in KVM stands for virtualization, not emulation.
Yes, but as I understand it...

WINE is not an emulator. So it needs to either (a) run on a native x86 hardware, or (b) run on emulated x86 hardware.
Bochs (for example) is an emulator, but not a hypervisor. It emulates a bare metal PC. So you can, for example, boot Windows on it. WINE is not an O/S, but in principle, you could run a bare-bones linux in Bochs with WINE on top. It would be slow. Alternatively, I could try to get hold of a legal copy of an old-enough Windows to run on Bochs and run the package I want. This is not my preferred option.
QEMU is an emulator with virtualization support, and it specifically has User Space Emulation mode User Space Emulation. This means that when WINE (compiled to run on ARM 32) makes the call to the x86 library, the call is caught by QEMU which emulates x86 on ARM. So you don't need to be running a Windows O/S. As I understand it, part of the magic which enables this is the Linux in-Kernel Virtual Machine support.
My reading of the Hangover project is that it is only targeted at 64-bit ARM. Implementation on 32-bit hosts is left as an SEP.

Now if I have completely misunderstood, and there will still be a relatively easy way to run an old Windows programm on the Pyra, I'd like to know what it is.

Of course, I might just have to wait '2 months' for the 64-bit ARM cpu board to be developed and made available...
 

Letalis Sonus

Advanced Member
Joined
Mar 5, 2009
Messages
1,343
As I understand it, part of the magic which enables this is the Linux in-Kernel Virtual Machine support.
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).
 

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
12,285
Location
Somewhere off the coast of the EU
Shame.
But on the other hand, will we benefit so much from newer Kernel?
You don't get security patches once a kernel drops out of support, which if it's not an LTS one happens as soon as the next x.xx kernel is in stable. The Pandora is on an LTS kernel, but even that kernel version dropped out of support a few months ago IIRC.

Plus sticking with a kernel means your peripherals get better over time. My wifi stick for example has improved since I bought it a few months ago. Sticking with an LTS kernel (which is what debian does by default BTW) means dodgy performers don't tend to improve.
 

Silent-Hunter

Hardcore Member
Joined
May 29, 2010
Messages
3,148
It sounds like the only way we'll be able to use this feature is it if we use a Pyra specific version of the kernel with the KVM support added back in.
 
Top