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.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 C2B2DC35666 for ; Sat, 22 Feb 2020 14:22:10 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 91D1D206EF for ; Sat, 22 Feb 2020 14:22:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZIb/CA8F"; 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 91D1D206EF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=yoshi.email Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Z9wl0oeP//p6s9JoTIpWjkjgIngAiLz1FJq1gHgxgL0=; b=ZIb/CA8FrZFf92wlCaVSXMPJJ TgXaHE6fkz6m57rKMYmxz80Bim78ZtgjM9KVxj3oQwHtDR0T6osDPHXiNUENhpVOXnt2FUtTwCznH H4c1RbtAdDXBBHcaOTRD5g9qtoATZ2fqzOJtV/Gvd9LFaUhBVnLsygeJSbA5IZ8UMFp69DaBuoARl YcinK1QOegoiPNrJrycFCqWNTGx1h7LeKBjBSiU29vlkifx3bOXGAglRFupIfjCI5R5StcN4gdQ3J HrNfAPY4Rt9Q0NzOs5sZDK0RNykchPVNjHSO+W2EgmpNkZnvoIJEHu0mBXwTzLEynfVSEpxMqgoIW dbBY1reYg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j5VfL-0007gl-GK; Sat, 22 Feb 2020 14:21:59 +0000 Received: from mail-gateway-shared10.cyon.net ([194.126.200.61]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j5VfH-0007gB-NO for linux-arm-kernel@lists.infradead.org; Sat, 22 Feb 2020 14:21:58 +0000 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-0000fG-A9 for linux-arm-kernel@lists.infradead.org; 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.infradead.org 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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200222_062156_231144_684A0433 X-CRM114-Status: GOOD ( 18.00 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Anders Berg , Vladimir Murzin , Russell King , Arnd Bergmann , Quentin Perret , Suzuki K Poulose , Christoffer Dall , James Morse , Paolo Bonzini , Will Deacon , Julien Thierry Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --MP_/la5n5ZAyUEQ7aLv=PFzS8nx--