All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Daniel Golle <daniel@makrotopia.org>
Cc: linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
Date: Wed, 19 Feb 2020 08:31:13 +0000	[thread overview]
Message-ID: <20200219083113.52c1a8fb@why> (raw)
In-Reply-To: <20200218213712.GD1382@makrotopia.org>

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!

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

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

  reply	other threads:[~2020-02-19  8:31 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.29637.1581344013.2486.linux-arm-kernel@lists.infradead.org>
2020-02-18 21:37 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Daniel Golle
2020-02-19  8:31   ` Marc Zyngier [this message]
     [not found]     ` <CGME20200220130838eucas1p12bc652ecd882204a8ffda5ed28f48bd5@eucas1p1.samsung.com>
2020-02-20 13:08       ` Bartlomiej Zolnierkiewicz
2020-02-20 13:39         ` Marc Zyngier
     [not found] <CGME20200210141344eucas1p25a6da0b0251931ef3659397a6f34c0c3@eucas1p2.samsung.com>
2020-02-10 14:13 ` Marc Zyngier
2020-02-10 14:13   ` Marc Zyngier
2020-02-10 14:13   ` Marc Zyngier
2020-02-10 15:21   ` Olof Johansson
2020-02-10 15:21     ` Olof Johansson
2020-02-10 15:21     ` Olof Johansson
2020-02-10 15:54     ` Arnd Bergmann
2020-02-10 15:54       ` Arnd Bergmann
2020-02-10 15:54       ` Arnd Bergmann
2020-02-10 15:46   ` Will Deacon
2020-02-10 15:46     ` Will Deacon
2020-02-10 15:46     ` Will Deacon
2020-02-10 16:25   ` Russell King - ARM Linux admin
2020-02-10 16:25     ` Russell King - ARM Linux admin
2020-02-10 16:25     ` Russell King - ARM Linux admin
2020-02-10 16:26     ` Russell King - ARM Linux admin
2020-02-10 16:26       ` Russell King - ARM Linux admin
2020-02-10 16:26       ` Russell King - ARM Linux admin
2020-02-11 15:12   ` Vladimir Murzin
2020-02-11 15:12     ` Vladimir Murzin
2020-02-11 15:12     ` Vladimir Murzin
2020-02-11 15:23   ` Catalin Marinas
2020-02-11 15:23     ` Catalin Marinas
2020-02-11 15:23     ` Catalin Marinas
2020-02-17  0:14   ` Linus Walleij
2020-02-17  0:14     ` Linus Walleij
2020-02-17  0:14     ` Linus Walleij
2020-02-19 13:53   ` Stefan Agner
2020-02-19 13:53     ` Stefan Agner
2020-02-19 13:53     ` Stefan Agner
2020-02-20 11:01     ` Marc Zyngier
2020-02-20 11:01       ` Marc Zyngier
2020-02-20 11:01       ` Marc Zyngier
2020-02-19 14:56   ` Christoffer Dall
2020-02-19 14:56     ` Christoffer Dall
2020-02-19 14:56     ` Christoffer Dall
2020-02-19 15:09   ` Arnd Bergmann
2020-02-19 15:09     ` Arnd Bergmann
2020-02-19 15:09     ` Arnd Bergmann
2020-02-19 15:46     ` Jan Kiszka
2020-02-19 15:46       ` Jan Kiszka
2020-02-19 15:46       ` Jan Kiszka
2020-02-20 10:29       ` Marc Zyngier
2020-02-20 10:29         ` Marc Zyngier
2020-02-20 10:29         ` Marc Zyngier
2020-02-20 12:44   ` Marek Szyprowski
2020-02-20 12:44     ` Marek Szyprowski
2020-02-20 12:44     ` Marek Szyprowski
2020-02-20 13:15     ` Marc Zyngier
2020-02-20 13:15       ` Marc Zyngier
2020-02-20 13:15       ` Marc Zyngier
2020-02-20 13:17       ` Paolo Bonzini
2020-02-20 13:17         ` Paolo Bonzini
2020-02-20 13:17         ` Paolo Bonzini
2020-02-20 13:32       ` Robin Murphy
2020-02-20 13:32         ` Robin Murphy
2020-02-20 13:32         ` Robin Murphy
2020-02-20 14:01         ` Marc Zyngier
2020-02-20 14:01           ` Marc Zyngier
2020-02-20 14:01           ` Marc Zyngier
2020-02-20 14:38           ` Robin Murphy
2020-02-20 14:38             ` Robin Murphy
2020-02-20 14:38             ` Robin Murphy
2020-02-22 14:21   ` Takashi Yoshi
2020-02-22 14:21     ` Takashi Yoshi
2020-02-22 14:40   ` Takashi Yoshi
2020-02-22 14:40     ` Takashi Yoshi
2020-02-22 14:40     ` Takashi Yoshi
2020-02-22 21:31     ` Arnd Bergmann
2020-02-22 21:31       ` Arnd Bergmann
2020-02-22 21:31       ` Arnd Bergmann
2020-02-25 21:34       ` Takashi Yoshi
2020-02-25 21:34         ` Takashi Yoshi
2020-02-25 21:34         ` Takashi Yoshi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200219083113.52c1a8fb@why \
    --to=maz@kernel.org \
    --cc=daniel@makrotopia.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.