Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20/02/2020 2:01 pm, Marc Zyngier wrote:
On 2020-02-20 13:32, Robin Murphy wrote:
On 20/02/2020 1:15 pm, Marc Zyngier wrote:
Hi Marek,

On 2020-02-20 12:44, Marek Szyprowski wrote:
Hi Marc,

On 10.02.2020 15:13, Marc Zyngier wrote:
KVM/arm was merged just over 7 years ago, and has lived a very quiet
life so far. It mostly works if you're prepared to deal with its
limitations, it has been a good prototype for the arm64 version,
but it suffers a few problems:

- It is incomplete (no debug support, no PMU)
- It hasn't followed any of the architectural evolutions
- It has zero users (I don't count myself here)
- It is more and more getting in the way of new arm64 developments

That is a bit sad information. Mainline Exynos finally got everything
that was needed to run it on the quite popular Samsung Exynos5422-based
Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
being used. We also use it internally at Samsung.

Something like "too little, too late" springs to mind, but let's be
constructive. Is anyone using it in a production environment, where
they rely on the latest mainline kernel having KVM support?

The current proposal is to still have KVM support in 5.6, as well as
ongoing support for stable kernels. If that's not enough, can you please
explain your precise use case?

Presumably there's no *technical* reason why the stable subset of v7
support couldn't be stripped down and brought back private to arch/arm
if somebody really wants and is willing to step up and look after it?

There is no technical reason at all, just a maintenance effort.

The main killer is the whole MMU code, which I'm butchering with NV,
and that I suspect Will will also turn upside down with his stuff.
Not to mention the hypercall interface that will need a complete overhaul.

If we wanted to decouple the two, we'd need to make the MMU code, the
hypercalls, arm.c and a number of other bits private to 32bit.

Right, the prospective kvm-arm maintainer's gameplan would essentially be an equivalent "move virt/kvm/arm to arch/arm/kvm" patch, but then ripping out all the Armv8 and GICv3 gubbins instead. Yes, there would then be lots of *similar* code to start with, but it would only diverge further as v8 architecture development continues independently.

Anyway, I just thought it seemed worth saying out loud, to reassure folks that a realistic middle-ground between "yay bye!" and "oh no the end of the world!" does exist, namely "someone else's problem" :)

Robin.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux