From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=0.9 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E5F5C35666 for ; Sat, 22 Feb 2020 19:17:41 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 2F418206E2 for ; Sat, 22 Feb 2020 19:17:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=yoshi.email header.i=@yoshi.email header.b="EhaeC908" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2F418206E2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=yoshi.email Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 8D8834AF01; Sat, 22 Feb 2020 14:17:39 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@yoshi.email Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO8ZY7goFwAB; Sat, 22 Feb 2020 14:17:36 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 96A304AF6B; Sat, 22 Feb 2020 14:17:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 835894AE8D for ; Sat, 22 Feb 2020 09:21:45 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJu-+m5Yh+V2 for ; Sat, 22 Feb 2020 09:21:43 -0500 (EST) Received: from mail-gateway-shared10.cyon.net (mail-gateway-shared10.cyon.net [194.126.200.61]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 9FA474ACEE for ; Sat, 22 Feb 2020 09:21:43 -0500 (EST) Received: from s054.cyon.net ([149.126.4.63]) by mail-gateway-shared10.cyon.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim) (envelope-from ) id 1j5Vf0-0000fI-Ac for kvmarm@lists.cs.columbia.edu; Sat, 22 Feb 2020 15:21:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=yoshi.email ; s=default; h=Content-Type:MIME-Version:References:In-Reply-To:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZCdFmEmVfie/TJObQdsbhfyS2HdQgThCT9yQgtLH/Ss=; b=EhaeC908wMEEPX0wU27URu2/9E +lk+XjYJBLNh8Vo7ZcOt3F5R+SjUH2IVRyorXoik+6Vhwm+O1RjyB9sgE5jTRdyJA0ZzMLWK4cT6N 2W1uRxSSdX0kMv8rV1dkB0w9/faCd/gCvCsIXrYrstlc+BecabXnY8MgCEyH5GY9vrFClO++6Qc3r d5r4AkZZfVe3smgU+svslu1cDEbK0UQgCc2p74wXU9suFEd/TFj20tX1wrlRPZrPS6Su8LJ6nCkbu TdJg6VwGVF/M9HGjZOqnqcVbN0ei252+w9ii8ys+yWyCMlzoYLv154tuLrJzGerSf5ZapWuZIaCkK O/GHbImg==; Received: from [10.20.10.231] (port=12860 helo=mail.cyon.ch) by s054.cyon.net with esmtpa (Exim 4.92) (envelope-from ) id 1j5Vey-006dye-UW; Sat, 22 Feb 2020 15:21:37 +0100 Date: Sat, 22 Feb 2020 15:21:34 +0100 From: Takashi Yoshi To: Marc Zyngier , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org Subject: Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Message-ID: In-Reply-To: <20200210141324.21090-1-maz@kernel.org> References: <20200210141324.21090-1-maz@kernel.org> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; armv7a-unknown-linux-gnueabihf) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/la5n5ZAyUEQ7aLv=PFzS8nx" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s054.cyon.net X-AntiAbuse: Original Domain - lists.cs.columbia.edu X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - yoshi.email X-Get-Message-Sender-Via: s054.cyon.net: authenticated_id: takashi@yoshi.email X-Authenticated-Sender: s054.cyon.net: takashi@yoshi.email X-Source: X-Source-Args: X-Source-Dir: X-OutGoing-Spam-Status: No, score=-1.1 X-Mailman-Approved-At: Sat, 22 Feb 2020 14:17:35 -0500 Cc: Anders Berg , Russell King , Arnd Bergmann , Paolo Bonzini , Will Deacon X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu --MP_/la5n5ZAyUEQ7aLv=PFzS8nx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi I found this mailing list thread and would like to express my opinion and dependence on KVM/arm32. I hope that I'm not too late already. On Monday, 10.02.2020, 14:13 +0000 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) I might not be an important user, but I have been for multiple years and still am a regular user of KVM/arm32 on different devices. I use KVM on my Tegra K1 Chromebook for app development and have multiple SBCs at home on which I run VMs on using KVM+libvirt. Sure, neither of these devices has many resources available, but they are working fine. I would love to keep them in service since I haven't found arm64-based replacements that don't require hours upon hours of tinkering to just get a basic OS installation running with a mainline kernel. As an example that they can still be of use in 2020 I'd like to point out that one of the SBCs is running my DNS resolver, LDAP server, RSS reader, IRC bouncer, and shared todo list just fine, each in their separate VM. > - It is more and more getting in the way of new arm64 developments > > 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. *scream* > One of the reasons that makes me confident nobody is > using it is that I never receive *any* bug report. Yes, it is > perfect. This assumption is deeply flawed. Most users (including me) are not subscribed to this mailing list and will never find this thread at all. I myself stumbled upon this discussion just by chance while I was browsing the web trying to find something completely unrelated. I've been using KVM on x86, ppc and arm for many years, yet I never felt the need to report a bug on the mailing list. (This is to be interpreted as a compliment to the great work the devs of KVM have done!) Just going by the number of bugs reported on a developers mailing list is not going to paint an accurate picture. I am convinced that I'm not the only one relying on KVM/arm32 in the mainline kernel and would ask you to please reconsider keeping arm32 in the mainline kernel for a few more years until adequate arm64 replacements are available on the market and have gained proper support in the mainline kernel. I myself unfortunately do neither have the knowledge nor resources to help with development in KVM or maintaining a non-mainline kernel. > But if you depend on KVM/arm being available in mainline, please > shout. > > To reiterate: 32bit guest support for arm64 stays, of course. Only > 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to > arm64, and cleanup all the now unnecessary abstractions. > > The patches have been generated with the -D option to avoid spamming > everyone with huge diffs, and there is a kvm-arm/goodbye branch in > my kernel.org repository. > > [...] Thanks for your understanding. Kind regards - Yoshi --MP_/la5n5ZAyUEQ7aLv=PFzS8nx Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Original html part"
Hi

I found this mailing list thread and would like to express my o= pinion and dependence on KVM/arm32.

I hope that I'm not too late already.


On Monday, 10.02.20= 20, 14:13 +0000 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 P= MU)
> - It hasn't followed any of the architectural evolutions
> - = It has zero users (I don't count myself here)

I might not be an importa= nt user, but I have been for multiple years and still am a regular user of = KVM/arm32 on different devices.

I use KVM on my Tegra K1 Chromebook for ap= p development and have multiple SBCs at home on which I run VMs on usi= ng KVM+libvirt.

Sure, neither of these devices has many resources available, but the= y are working fine. I would love to keep them in service since I haven= 't found arm64-based replacements that don't require hours upon hours of ti= nkering to just get a basic OS installation running with a mainline ke= rnel.
<= br>
As = an example that they can still be of use in 2020 I'd like to point out that= one of the SBCs is running my DNS resolver, LDAP server, RSS&nbs= p;reader, IRC bouncer, and shared todo list just fine, each in their separa= te VM.
=
> - It is more and more getting in the w= ay of new arm64 developments
>
> So here it is: unless someon= e screams and shows that they rely on
> KVM/arm to be maintained upstea= m, I'll remove 32bit host support
> form the tree.
=

*scream*=

> One of the reasons that makes me confident nobody = is
> using it is that I never receive *any* bug report. Yes, it is
> pe= rfect.

This assumption is deeply flawed. Most users (including me) are = not subscribed to this mailing list and will never find this thread at all.=
I myse= lf stumbled upon this discussion just by chance while I was browsing the we= b trying to find something completely unrelated.

I've been using KVM on x86, ppc and= arm for many years, yet I never felt the need to report a bug on the = mailing list.
(This is to be interpreted as a compliment to the great work the dev= s of KVM have done!)

Just going by the number of bugs reported on a developers= mailing list is not going to paint an accurate picture.

I am convinced that I'm not= the only one relying on KVM/arm32 in the mainline kernel and would ask you= to please reconsider keeping arm32 in the mainline kernel for a few more y= ears until adequate arm64 replacements are available on the market and have= gained proper support in the mainline kernel.

I myself unfortunately do neither h= ave the knowledge nor resources to help with development in KVM or mai= ntaining a non-mainline kernel.

=
> But if you depend on KVM/arm being available in = mainline, please
= > shout.
>
<= span class=3D"-x-evo-quote-character">> To reiterate: 32bi= t guest support for arm64 stays, of course. Only
> 32bit host goes. Onc= e this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup a= ll the now unnecessary abstractions.
>
> The patches have been= generated with the -D option to avoid spamming
> everyone with huge di= ffs, and there is a kvm-arm/goodbye branch in
> my kernel.org reposito= ry.
>
> [...]

Thanks for your understanding.

Kind regards

- Yoshi
--MP_/la5n5ZAyUEQ7aLv=PFzS8nx Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm --MP_/la5n5ZAyUEQ7aLv=PFzS8nx--