From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757262AbcAYQ05 (ORCPT ); Mon, 25 Jan 2016 11:26:57 -0500 Received: from mout.kundenserver.de ([217.72.192.75]:65492 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757200AbcAYQ0y (ORCPT ); Mon, 25 Jan 2016 11:26:54 -0500 From: Arnd Bergmann To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Christoffer Dall , kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v2 00/21] arm64: Virtualization Host Extension support Date: Mon, 25 Jan 2016 17:26:17 +0100 Message-ID: <1602215.WjO3PgfQ53@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <56A64C09.4060702@arm.com> References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com> <2703557.vyWRuMlGU2@wuerfel> <56A64C09.4060702@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:3hixCn0V9rJJp0BkAC89xtooD0itaS3VcECxpvepkPliksaHdTw Fs0F9txhJA9QL25lFCtwMgMZ4xJMD+2niytfQNBb+Pz1fDnNdMGAeyZn7PIDU32LkUpSS2p wdzbrxQ6dBDh5pjhVf9XRRCTN/CG8aBU3xPQzqWKlqbXz9nw26/MIjjuFN+90vgl2eyEU6D vN7a++TbYvngcwewfSxeQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:iQkaUw9HRxY=:hBlPpv7atGoBgmIAd46We2 jEsd13HRrKZgV1BhpsHTYEnwYwuMCXv4AOGAtopmgDJDiKyEs/HsL1Fy41GbhxwU9DZTNo/I+ HkIZODqJuBZPpix3mxNzS/ZWVYDRAh1kGo9kCslC13DELcrfx6YQHC/yUMEVFFLXqHhxZGAnz t1zCGrM4hP4t14iuAmovNl/T8c4Wf2z384IghC2t0rSrK/gICWjQ60xgfjWDGPiL7XM5BjS43 vqPZuHoxiSQNPYG2h2leQtIdbfS1MGx9QZ7U2vwOCOyQBgyFevY6UJT5soUNoW5vr7BcUsRkg te/ifZr56Hh3aD9XbvxQ7nvee9kiUUsr+5yIIkEnsaPSW07PFd6oW+T3aCJKj78A4f4QD5nx+ dTAdwI/RCHCL1EXOhDXuKgoe3PZVK5Moas2qVhnrsP9rEAw4+KFLJNqRoR95EmONadmKoEm/3 axteu3pesYy+6i5YSrEjuqXW/b9bGkppVLQGO1yvcaRWBJfDCTFsi+P3nmwvoJ5R6nc4H4UVb 876FVGPmCFjC6kQuKaBRCYXMTnbo5jVn8FpZkta/FNB9Nl/KvocoQG3gRkIMDMKNIniIisER4 I2TsU7XC/CZx96HjAiyOh8ObhkClYLfesF7qg1/PVvbA+9/RkWQs2vPOePJlKtaroMAZae86b oU2jnIlRW4M6YRooZcf3Oh5iQZKV//IaJiVbtUs1NS5G7ZouKD4qXok8/qH/xjueT0XbmOFxK I07YIJb3wsZ5TSsTbj1PKI4l3/URbhwjVM/A3LUhrZuCkOnZgslfg66ouQSyCMfOmr7x5Qz7y 6Aav1TlZ7litizZYmBWA5//PDg7+Q== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 25 January 2016 16:23:37 Marc Zyngier wrote: > On 25/01/16 16:15, Arnd Bergmann wrote: > > On Monday 25 January 2016 15:53:34 Marc Zyngier wrote: > >> host and guest, reducing the overhead of virtualization. > >> > >> In order to have the same kernel binary running on all versions of the > >> architecture, this series makes heavy use of runtime code patching. > >> > >> The first 20 patches massage the KVM code to deal with VHE and enable > >> Linux to run at EL2. The last patch catches an ugly case when VHE > >> capable CPUs are paired with some of their less capable siblings. This > >> should never happen, but hey... > >> > >> I have deliberately left out some of the more "advanced" > >> optimizations, as they are likely to distract the reviewer from the > >> core infrastructure, which is what I care about at the moment. > > > > One question: as you mention that you use a lot of runtime code patching > > to make this work transparently, how does this compare to runtime patching > > the existing kernel to run in EL2 mode without VHE? Is that even possible? > > I haven't explored that particular avenue - by the look of it, this > would require a lot more work, as v8.0 EL2 lacks a number of features > that Linux currently requires (like having two TTBRs, for example). Ok, I see. > > My interpretation so far as always been "that's too complicated to > > do because it would require a lot of runtime patching", but now we seem > > to get that anyway because we want to run a hypervisor-enabled kernel in > > either EL1 or EL2 depending on the presence of another feature. > > The kernel itself is mostly untouched (what runs at EL1 also runs at EL2 > without any patching, because the new EL2 is now a superset of EL1). It > is the hypervisor code that gets a beating with the code-patching stick. Thanks for the explanation, makes sense. Arnd