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.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 CEDFDC35666 for ; Sat, 22 Feb 2020 21:31:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A3ECA20707 for ; Sat, 22 Feb 2020 21:31:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726855AbgBVVbx (ORCPT ); Sat, 22 Feb 2020 16:31:53 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:53325 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726828AbgBVVbx (ORCPT ); Sat, 22 Feb 2020 16:31:53 -0500 Received: from mail-lf1-f54.google.com ([209.85.167.54]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.129]) with ESMTPSA (Nemesis) id 1N4Qg2-1jXd3Z2Bz4-011Vfk for ; Sat, 22 Feb 2020 22:31:51 +0100 Received: by mail-lf1-f54.google.com with SMTP id s23so4045693lfs.10 for ; Sat, 22 Feb 2020 13:31:51 -0800 (PST) X-Gm-Message-State: APjAAAVPN6Edewv5IfjND7P5mUX1BfBzILFhT7bEOcV4pWUvKFYIS22o mU9UAJRP0FvN5k4dXLsPRawCp++JP+g2lj0n0ro= X-Google-Smtp-Source: APXvYqw08WaVpwqyvapB9jwmtZ9FkkkQyrz5uYJ12nY2XRMB6nrK7EaFW5taPH3fOq3Exia34Hd+8TSqfX93FnPLHNA= X-Received: by 2002:ac2:5f62:: with SMTP id c2mr4862268lfc.207.1582407110902; Sat, 22 Feb 2020 13:31:50 -0800 (PST) MIME-Version: 1.0 References: <20200210141324.21090-1-maz@kernel.org> <20200222154030.5625fa5f.takashi@yoshi.email> In-Reply-To: <20200222154030.5625fa5f.takashi@yoshi.email> From: Arnd Bergmann Date: Sat, 22 Feb 2020 22:31:40 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host To: Takashi Yoshi Cc: Marc Zyngier , Linux ARM , kvmarm@lists.cs.columbia.edu, kvm list , Anders Berg , Vladimir Murzin , Russell King , Suzuki K Poulose , Quentin Perret , Christoffer Dall , James Morse , Paolo Bonzini , Will Deacon , Julien Thierry Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:APoqwatqbfIzGXAsvG7xy8LcNuXilxk/dB0h2dlnr8xxMEpp28Z Vtd4qz7CGiuouS2MGkdw01eSTAgVFuQH25g1CQVOH8sbxw2wjdGMreU8XsOZl92GPOjpCY8 TEp8+R/iyl+59nzwn9XuaG0dWL1BlecVDkICw4E9eurRzobyGdG/J2Fr1JhXBW6T2tFrL3k kvpdl/PU9+TjORTxPyvqw== X-UI-Out-Filterresults: notjunk:1;V03:K0:xtf71T0M97I=:kH8MH3KzLkZPBj+5bhJQCG s+kiy3nzRgDBpyitRHa4u0rplnX6rOcWfz/BEUX8WZrM2pXGhNDO5WTJYIuDMN4B2hQYexKmE Atm7vm+UbnM/HAdEIyP/WIUdFAOBVWK4usAgZGClWjH6VV8pgAfe5A+KAKnPpyOaH2l2WQv3z qw4TNERc7iy0uaPrBd2GU+mz5ZTexQFr168oGQBd8zJ7p3PtQ1Wp7qz5bM7gAsgzt6n4PwDa9 lXR25TG4WGAv/csBL9TofK2JEbri61yYbfKB8E1CvwIOb8keNsXZIGrmYL7CthKqw+OfCSvCh 3H+QtWdcWPLRmyZR/cksLMmjlWUDGMcFTckd7vT51Ek9hzkEBgKsI+L+3ssT+5SSAyJ/zo1Is mk4JtqFHjZQs4phVxfwtDby7aS2CbKkaRjKWt1Vyv3Uis8ku91lTv0qmJcEC5yNcdZIzfnPXH /N5FOg6sxZ4P4QbqYCNU/pqZKYGvYXZyDy7mfX+GNeknZ5dNABpNh4zRbejZGKD7+BrkG5yil EOJsw8SDTJ/6OwfeG7UGwee3yEaUDRSrvcHSbkv0DI6GDDgX1FSZ21tYaSiNdKseJsuWqTu4Q esWVzo1UvfmvTCvHWB9rzS50EFx+GKNLNUeLUWu6pSHR0Lla0cXSLqr2Z6apUOB0wn564WziA JQNQQQIGwXy01TVj48i2uvTW+tlpVkiv6qp1DKRQAMzxGiAHs4/C+vcudsfmeiouel8uw3Une 1ALze0fkdLfId7i/JIDis/HxNcK+N3SahXB6F6zQLjgFKBHH1ZTqRDT0Ejm3lYGK0JTvaGYiX I8sLimM+0xjvLjxt9F2t1WU5kHf03r48yImfRu1tcntMaAEgk0= Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Sat, Feb 22, 2020 at 3:40 PM Takashi Yoshi wrote: > 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. Thank you for providing an important data point to this question. > > - 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. Can you provide some more information about how you use KVM on 32-bit machines, to make it possible to better estimate how many others might do the same, and how long you will need to upgrade to newer kernels for? In particular: - What is the smallest amount of physical RAM that you have to found to make a usable ARM/KVM host? Note that the 4GB configuration of the Tegra K1 (an rk3288) Chromebooks seems to be extremely rare in other devices, while most new 32-bit SBCs come with 1GB or less these days. - How often do you update the host kernels on those 32-bit machines that you still use to newer releases? What is the oldest/newest you run at the moment? - Are you able to move the host installation to a distribution with a long-term stable release cycle such as Debian, Ubuntu that gives you a ~five year support after a kernel release? Arnd 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.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 8C60AC35671 for ; Sat, 22 Feb 2020 21:31:58 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 224AD206EF for ; Sat, 22 Feb 2020 21:31:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 224AD206EF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de 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 722DB4AF32; Sat, 22 Feb 2020 16:31:57 -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 9Dbn1JI2QmbS; Sat, 22 Feb 2020 16:31:56 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 62E1F4AEC0; Sat, 22 Feb 2020 16:31:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 17A714ACE6 for ; Sat, 22 Feb 2020 16:31:55 -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 pSnxKZ2jmRcJ for ; Sat, 22 Feb 2020 16:31:53 -0500 (EST) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id A80E24AC07 for ; Sat, 22 Feb 2020 16:31:53 -0500 (EST) Received: from mail-lf1-f41.google.com ([209.85.167.41]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MtOOm-1jQzDC1MdC-00uumT for ; Sat, 22 Feb 2020 22:31:52 +0100 Received: by mail-lf1-f41.google.com with SMTP id b15so4071579lfc.4 for ; Sat, 22 Feb 2020 13:31:51 -0800 (PST) X-Gm-Message-State: APjAAAUmYQX/QZRzVUGoxCdMGXhWeYHkS7XV9fTtjgUnVuOQNg3Y8fsi JIAocu1HnWioYTlZPXQP819rtvilyJNubyQKJMA= X-Google-Smtp-Source: APXvYqw08WaVpwqyvapB9jwmtZ9FkkkQyrz5uYJ12nY2XRMB6nrK7EaFW5taPH3fOq3Exia34Hd+8TSqfX93FnPLHNA= X-Received: by 2002:ac2:5f62:: with SMTP id c2mr4862268lfc.207.1582407110902; Sat, 22 Feb 2020 13:31:50 -0800 (PST) MIME-Version: 1.0 References: <20200210141324.21090-1-maz@kernel.org> <20200222154030.5625fa5f.takashi@yoshi.email> In-Reply-To: <20200222154030.5625fa5f.takashi@yoshi.email> From: Arnd Bergmann Date: Sat, 22 Feb 2020 22:31:40 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host To: Takashi Yoshi X-Provags-ID: V03:K1:B7leW59WFsf1YO0Lf1fgzxgOX2ow/i4slqj0vUles4qR1dNrhZP +j4yTSDzYA4ACrvBUc0W4OVjqEWecNq+86Xo+WJU9iYKuXL48TVtfRQlgVQj8cDQH7prOCF GEsFsRWszwWPi2fUfXjiNax7nIbY5MboA5tnz1CGIjq8NczCesJpyEGmsD81TO9+q5FSzOS LXnCZTQqFvM1ZoercdA8Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:3TykgSv4Nho=:VEa9BEU29rGEWzccunJThr 1dJ+8BG6Bo22eLqYJGXnhS25ISVpl48CG3c82yqPUjYDbj1uNpJBrDw6AqiXCX0rXV3m2+FBX dKNqbhByqKp/iiOk4qpAVPASGI9nfo4Bgj74E0xtEupYVS2dwu0g05j8SYoI2o6POAR+3i76K cMqaL2jl5AS7L9U3UYW/mIAx+TtIGwZTzu+DF62Tk86AurJ18EWScLksbuNO5smtxbes7dHxF HL7MOI8XyDFu+h1FMErOxguhPxweq/jHXw3gTvNhS+yMfdtOc9q6gPfT3zDAsJIKLkpB4Al7b 6//me0GGnguJdMq6eruvkn8/qTUIiD2HtowAwEVQ980nhhAuCdB1qN3YknLbkNTCwu2sA9Xi4 W9u4aZqBlNaVEy3atM/HInKHxXAJjn0RkbFIFlU6p6T3Do6svi6zNKyReyaZ8c4+N9nA6mIAA CYFIKXQvR3K4B+M8ohcN8Jtx2RzqTMhoD37wcLoyzP6UnTz3hLe9tcG7JrrOucR042itN34yk LSgXYKXk8xQ8SuQ1/FW5dm/AnFNXlsknz3APVq//Ob90viHA3IBhsiRKuD7ynsr/mutzd4mQT 9D031NEME9D53TaTAtr4tJnAW6J/3XOHUVlECeA+E4OBT4M7FKi9KbEyOYFrQJ3EqVH1xdJG5 AElwgiL2f1a1O3DoIqfnGUPfnUnefxq4QtDOavnzDTB2nn8sZYLhTnlDz2RLGnC18zLQVtK0B OoFZdPwkvN2po4E0LhMrzggYIOVjMWer9DKQBHkFAx2qHIgKA0HT7bKRZvRyFYrcMCXqzcMmK CfxWdfsOGDyh31dHCZYZ46Tdg78E4sk4M0Lm2DOAGx28Q3LL4A= Cc: Anders Berg , Russell King , kvm list , Marc Zyngier , Paolo Bonzini , Will Deacon , kvmarm@lists.cs.columbia.edu, Linux ARM 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Sat, Feb 22, 2020 at 3:40 PM Takashi Yoshi wrote: > 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. Thank you for providing an important data point to this question. > > - 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. Can you provide some more information about how you use KVM on 32-bit machines, to make it possible to better estimate how many others might do the same, and how long you will need to upgrade to newer kernels for? In particular: - What is the smallest amount of physical RAM that you have to found to make a usable ARM/KVM host? Note that the 4GB configuration of the Tegra K1 (an rk3288) Chromebooks seems to be extremely rare in other devices, while most new 32-bit SBCs come with 1GB or less these days. - How often do you update the host kernels on those 32-bit machines that you still use to newer releases? What is the oldest/newest you run at the moment? - Are you able to move the host installation to a distribution with a long-term stable release cycle such as Debian, Ubuntu that gives you a ~five year support after a kernel release? Arnd _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 3F3BAC35666 for ; Sat, 22 Feb 2020 21:32:18 +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 0EC88206EF for ; Sat, 22 Feb 2020 21:32:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="tHZdq+8B" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0EC88206EF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de 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: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=z1K8a7L2Z7ZWQyLWEYixbKI+yYxncUQH7wHF+y9UmF4=; b=tHZdq+8B1HDYdQ +q2tK+DstZkwNadjEFsVP80Wh6LiporwB9URrHDuKzaFim8NqBJ3FXbPcusJ/6KQTiY1d+1nawhEM 7kPQw5Vrvm0zm+wTpCBj1x04LAyQS0VaVZAGMy+Ig3SD8BnEmEexhDS6SNWzvKVwTB6o0eJ2WBLrU aAnp7IhCVjKlOQ316M+7lgGtF6qcM+js05pYsnUOoPtlPk2KQ5dWNpzaCX0YU0KfT1SWu3EdW0ejm meVMQ2U0hza60t9yfVFbjDkxl78yuR5qeI1vqPNM4WmxbxteY+DGIPxBD7QPP10OzAuaBzzGOaoR+ tkTROIlwFav9MBiMLMlg==; 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 1j5cNZ-0002q3-Pc; Sat, 22 Feb 2020 21:32:05 +0000 Received: from mout.kundenserver.de ([212.227.17.13]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j5cNV-0002ow-9l for linux-arm-kernel@lists.infradead.org; Sat, 22 Feb 2020 21:32:03 +0000 Received: from mail-lf1-f49.google.com ([209.85.167.49]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MQ5jC-1ijfeC2UWe-00M6Lu for ; Sat, 22 Feb 2020 22:31:52 +0100 Received: by mail-lf1-f49.google.com with SMTP id 7so4045341lfz.11 for ; Sat, 22 Feb 2020 13:31:51 -0800 (PST) X-Gm-Message-State: APjAAAXhLulIc6iJqn/+8U8msRE+i6b3OMbTKo8ywClaj4+QMFzFkUrD mZ385A016RDLYGuaFAR0nbLI0HrHjjJkl2rLEjU= X-Google-Smtp-Source: APXvYqw08WaVpwqyvapB9jwmtZ9FkkkQyrz5uYJ12nY2XRMB6nrK7EaFW5taPH3fOq3Exia34Hd+8TSqfX93FnPLHNA= X-Received: by 2002:ac2:5f62:: with SMTP id c2mr4862268lfc.207.1582407110902; Sat, 22 Feb 2020 13:31:50 -0800 (PST) MIME-Version: 1.0 References: <20200210141324.21090-1-maz@kernel.org> <20200222154030.5625fa5f.takashi@yoshi.email> In-Reply-To: <20200222154030.5625fa5f.takashi@yoshi.email> From: Arnd Bergmann Date: Sat, 22 Feb 2020 22:31:40 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host To: Takashi Yoshi X-Provags-ID: V03:K1:INSxYxS3EfKBhKrjAg8YOzdaJ80sIWP2/7MXPuBaekg04BZC8zM 4u2qFc/iSSKOWzB/fSQtHUsu0phHb1FOwlCAFfg6wYNd3WAOUfhGqWXt044PGBhO0fCpSFd ahkOMbs30XwxZY/F4jSrGfNX+jP/0fJiFi3RudMubbA732Hr/Tq382YaVGGJy08u7m9SOJU gnKgJG5hiNchnxZXPfisA== X-UI-Out-Filterresults: notjunk:1;V03:K0:tKIG9PEum8U=:smWscvzp7KuVpnfv5UItAb EGdixgdcnRAD7FhMoEkGXS3srveSShbfx+Cx/Pc7X7tTWTLE48AwXz+g4A9Dn8HZnm1akPqhJ nOgvwSMi9WIGJlKOgfvAMz9E0y5GY4MYluDwCGw7UDQxVIkRg32YJeLVAmNhtpq53G5+cb81C NS+q/EPQ/TD4NG77n83Z0Q8owcVtzD2gPhkwXk/I/jGvLQ0EG/7LyCUISd4GETuFay4a8aY+7 SHbezglSbX4R6duQdFx96xF2IEZFM1mAuDMPFBnhVo2dbG7mYb6I4txjAg5ClDumio0lUOXTh X1rJrXGVJRNTE4wwkymEZjPkanO5LcXiQEb8CLNDeSTYcOgVXCJF3xy3xnptwaUbUUcZkiyd6 r2udAioHuUbeHA4twLrUd7LK0hepTW156+DzjPCArZuyljGOoLwD3t7iM6vxAuZEDn+H9Ox8H w3+9r5+hGQa1kgPjISxYAN0OEHEG08sqV7JhQn0P5o6i7rIvdraCGrHSP1EiSl9Gjmh9snUmQ VueXK0NHNa66DGhce6H/ClpWXvxcw054gzFODBSVZHXN8+7+/4OQEngDl0fyzAaY3J859VFwo UYSQ5zMQAwNX7ugpdC7Q6noc8hYaVmh4/bwruuOqtrBHTUUaqdQhRPSG3JvUOeJ42rsJ09JsZ jgZu9iwhOXudPGjuMOKdjkJk5CpMusJURLNjASaDKao/cJE9OUupX04oFMDhADiyvXFe2v1ju zi+04e9zu33DYXJR3V3sukOSbOmLksa7vVreRzBxc9egus2BmK6giNckM+1zs1eC9Mr/AGLcd NDCc3MxjTKKQASkRtQFXk7G5y+3VbnG7ZH5au96pYBcoL+uM1U= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200222_133201_634457_1464D423 X-CRM114-Status: GOOD ( 29.59 ) 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 , kvm list , Suzuki K Poulose , Marc Zyngier , Quentin Perret , Christoffer Dall , James Morse , Julien Thierry , Paolo Bonzini , Will Deacon , kvmarm@lists.cs.columbia.edu, Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, Feb 22, 2020 at 3:40 PM Takashi Yoshi wrote: > 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. Thank you for providing an important data point to this question. > > - 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. Can you provide some more information about how you use KVM on 32-bit machines, to make it possible to better estimate how many others might do the same, and how long you will need to upgrade to newer kernels for? In particular: - What is the smallest amount of physical RAM that you have to found to make a usable ARM/KVM host? Note that the 4GB configuration of the Tegra K1 (an rk3288) Chromebooks seems to be extremely rare in other devices, while most new 32-bit SBCs come with 1GB or less these days. - How often do you update the host kernels on those 32-bit machines that you still use to newer releases? What is the oldest/newest you run at the moment? - Are you able to move the host installation to a distribution with a long-term stable release cycle such as Debian, Ubuntu that gives you a ~five year support after a kernel release? Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel