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

[Marc Zyngier <maz@kernel.org>]

On 2020-02-20 13:08, Bartlomiej Zolnierkiewicz wrote:
> Hi Marc,
> 
> On 2/19/20 9:31 AM, Marc Zyngier wrote:
>> On Tue, 18 Feb 2020 22:37:12 +0100
>> Daniel Golle <daniel@makrotopia.org> wrote:
>> 
>> Daniel,
>> 
>> Please keep people on cc, it helps with the discussion.
>> 
>>>> Message-ID: <20200210141324.21090-1-maz@kernel.org>
>>>> 
>>>> 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)
>>> 
>>> Not true. At least I'm using KVM on CortexA7 (sun7i aka. Allwinner 
>>> A20)
>>> and it has been quite useful until now (running low memory footprint
>>> OpenWrt-based guests on yocto/OpenEmbedded host)
>> 
>> OK, so we have a user!
> 
> We have also started using it recently (as described by Marek in
> https://lore.kernel.org/linux-arm-kernel/621a0a92-6432-6c3e-cb69-0b601764fa69@samsung.com/#t
> ).

As I said in reply to Marek, that's not much of an explanation on
*how* you're using it, and how dependent you are on the feature being
available. "We use it internally" means nothing to me.

>>>> - It is more and more getting in the way of new arm64 developments
>>> 
>>> Can you elaborate more on how it is getting in the way? Just in terms
>>> of effort to maintain the necessary abstractions or does something
>>> really block ARM64 KVM support?
>> 
>> Useless abstractions are indeed one of the problems. Essentially,
>> KVM/arm has become a pile of empty stubs that are added to make the
>> thing compile. This doesn't bode well for the future.
>> 
>> The other aspect is that new features appearing on arm64 (nested virt,
>> enclaves, and potentially some more) are tearing the code-base apart,
>> and doing so while keeping 32bit alive and kicking would be a
>> challenge. I'm not saying it is impossible, just that it is hard, and
>> for very little gain, specially given that *nobody* contributes to the
>> port.
> 
> I have very basic knowledge of virt/kvm/arm/ codebase (so my question
> may be quite stupid) but wouldn't it be possible to split the codebase
> into legacy virt/kvm/arm32/ and virt/kvm/arm64/ parts (this would cause
> some code duplication but at the same time would stop 32bit port from
> blocking new developments for 64bit one)?

Sigh... "some code duplication" is a wee bit of an understatement:

$ find virt/kvm/arm -name '*.[ch]'| xargs wc -l
   2449 virt/kvm/arm/mmu.c
    378 virt/kvm/arm/trace.h
    988 virt/kvm/arm/vgic/vgic-mmio.c
    543 virt/kvm/arm/vgic/vgic-init.c
   2776 virt/kvm/arm/vgic/vgic-its.c
    546 virt/kvm/arm/vgic/vgic-mmio-v2.c
    321 virt/kvm/arm/vgic/vgic.h
    141 virt/kvm/arm/vgic/vgic-irqfd.c
     38 virt/kvm/arm/vgic/trace.h
    693 virt/kvm/arm/vgic/vgic-v3.c
   1011 virt/kvm/arm/vgic/vgic.c
    741 virt/kvm/arm/vgic/vgic-kvm-device.c
   1047 virt/kvm/arm/vgic/vgic-mmio-v3.c
    451 virt/kvm/arm/vgic/vgic-v4.c
    300 virt/kvm/arm/vgic/vgic-debug.c
    208 virt/kvm/arm/vgic/vgic-mmio.h
    504 virt/kvm/arm/vgic/vgic-v2.c
    200 virt/kvm/arm/mmio.c
    869 virt/kvm/arm/pmu.c
    525 virt/kvm/arm/psci.c
     71 virt/kvm/arm/hypercalls.c
   1180 virt/kvm/arm/arch_timer.c
    131 virt/kvm/arm/pvtime.c
   1723 virt/kvm/arm/arm.c
    204 virt/kvm/arm/aarch32.c
     57 virt/kvm/arm/perf.c
   1130 virt/kvm/arm/hyp/vgic-v3-sr.c
     49 virt/kvm/arm/hyp/timer-sr.c
    136 virt/kvm/arm/hyp/aarch32.c
  19410 total

The most complicated parts (the MMU code, the GIC support, the timers)
will all go through drastic changes in the coming months (just go 
through
the NV series, for example). Do I want to duplicate this and maintain it
as a separate port? The answer is obviously *NO WAY*.

If someone volunteers and wants to do that, that's their call. But 
somehow
I doubt you'll find anyone willing to do this.

The alternative is to mark KVM/arm as orphaned, let it bit-rot, and then
remove it, ia64 style. The benefit? None whatsoever. I'd rather remove 
it
while it is in a good state and maintained in all stable kernels.

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel