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=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 A95F6C34047 for ; Wed, 19 Feb 2020 15:47:22 +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 7A1C52464E for ; Wed, 19 Feb 2020 15:47:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZOrV8vvl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7A1C52464E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=siemens.com 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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Tl8BH9DdxW6KGdNpGMw3FQwxFT09/IPIQ3ygzfvqLWs=; b=ZOrV8vvlbE/76+bA1paFe0EEg /sJfFe/MP93gnsWEOpwbVmLjlN1mKh2z5+TemWRBVZY1/RAmtcEZBI/8mp7RQlaXnh4YdyugOW6xS kFwOEa977L19gbzXN1MjQkFWOpUsmX7Ye/RAxIJmdwhgq6RTQ2AmomYkhtOjC7c7CuQa/t/vDoR7v KsW1UzlPVcv7Mw1KJGdinSh5maEGtSOG5v4CS1mTtNxnrmFda6NL3F4lQYeO8b1u25GKk77i/hs/B sl7Ri+lLOsRvKDrgMYQN8KU7X7mMIU+UsIAgoAaIg5Ug7wPU0XrykKAv+VP2UGTDe5fsCfOD7sGia JgepsQCAA==; 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 1j4RZD-0001Ia-Dg; Wed, 19 Feb 2020 15:47:15 +0000 Received: from goliath.siemens.de ([192.35.17.28]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j4RZA-0001I2-1d for linux-arm-kernel@lists.infradead.org; Wed, 19 Feb 2020 15:47:13 +0000 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id 01JFkkEi023113 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Feb 2020 16:46:46 +0100 Received: from [139.25.68.37] ([139.25.68.37]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 01JFkgTh026670; Wed, 19 Feb 2020 16:46:42 +0100 Subject: Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host To: Arnd Bergmann , Marc Zyngier References: <20200210141324.21090-1-maz@kernel.org> From: Jan Kiszka Message-ID: Date: Wed, 19 Feb 2020 16:46:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200219_074712_396466_3DBC0168 X-CRM114-Status: GOOD ( 21.72 ) 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: jailhouse-dev@googlegroups.com, Anders Berg , Vladimir Murzin , Russell King , kvm list , Suzuki K Poulose , jean-philippe.brucker@arm.com, Quentin Perret , Christoffer Dall , James Morse , Linux ARM , Paolo Bonzini , Will Deacon , kvmarm@lists.cs.columbia.edu, Julien Thierry Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 19.02.20 16:09, Arnd Bergmann wrote: > On Mon, Feb 10, 2020 at 3:13 PM 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) >> - 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. 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. >> >> 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. > > Just one more thought before it's gone: is there any shared code > (header files?) that is used by the jailhouse hypervisor? > > If there is, are there any plans to merge that into the mainline kernel > for arm32 in the near future? > > I'm guessing the answer to at least one of those questions is 'no', so > we don't need to worry about it, but it seems better to ask. Good that you mention it: There is one thing we share on ARM (and ARM64), and that is the hypervisor enabling stub, to install our own vectors. If that was to be removed as well, we would have to patch it back downstream. So far, we only carry few EXPORT_SYMBOL patches for essential enabling. That said, I was also starting to think about how long we will continue to support Jailhouse on 32-bit ARM. We currently have no supported SoC there that comes with an SMMU, and I doubt to see one still showing up. So, Jailhouse on ARM is really just a testing/demo case, maybe useful (but I didn't get concrete feedback) for cleaner collaborative AMP for real-time purposes, without security concerns. I assume 32-bit ARM will never be part of what would be proposed of Jailhouse for upstream. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel