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

[Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>]

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
).

>>> - 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)?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

>>> So here it is: unless someone screams and shows that they rely on
>>> KVM/arm to be maintained upsteam, I'll remove 32bit host support
>>> form the tree. One of the reasons that makes me confident nobody is
>>> using it is that I never receive *any* bug report. Yes, it is perfect.
>>> But if you depend on KVM/arm being available in mainline, please shout.  
>>
>> I cetainly don't depend on it, meaning I'd have to replace hardware
>> worth less than $100 in the near future, that's not too bad.
>> And yes, it has just been working perfectly ;)
> 
> I'm really glad it works well. Note that it isn't like we are taking it
> away from you. 5.6 will still have it, and I will still maintain it as
> part of the stable tree. It is just that I've come to the sad
> conclusion that as a community, we need to move on.
> 
> 	M.
> 
> PS: and if you find a decent, reliable machine to replace your A20,
> please let me know. All the arm64 SBCs I've seen are utter crap
> compared to my Cubietruck...

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