From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Wed, 30 Nov 2011 18:15:01 +0000 Subject: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions In-Reply-To: <1322670473.31810.129.camel@zakaz.uk.xensource.com> References: <201111301432.54463.arnd@arndb.de> <1322670473.31810.129.camel@zakaz.uk.xensource.com> Message-ID: <201111301815.01297.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wednesday 30 November 2011, Ian Campbell wrote: > On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote: > > On Wednesday 30 November 2011, Ian Campbell wrote: > > What I suggested to the KVM developers is to start out with the > > vexpress platform, but then generalize it to the point where it fits > > your needs. All hardware that one expects a guest to have (GIC, timer, > > ...) will still show up in the same location as on a real vexpress, > > while anything that makes no sense or is better paravirtualized (LCD, > > storage, ...) just becomes optional and has to be described in the > > device tree if it's actually there. > > That's along the lines of what I was thinking as well. > > The DT contains the address of GIC, timer etc as well right? So at least > in principal we needn't provide e.g. the GIC at the same address as any > real platform but in practice I expect we will. Yes. > In principal we could also offer the user options as to which particular > platform a guest looks like. At least when using a qemu based simulation. Most platforms have some characteristics that are not meaningful in a classic virtualization scenario, but it would certainly be helpful to use the virtualization extensions to run a kernel that was built for a particular platform faster than with pure qemu, when you want to test that kernel image. It has been suggested in the past that it would be nice to run the guest kernel built for the same platform as the host kernel by default, but I think it would be much better to have just one platform that we end up using for guests on any host platform, unless there is a strong reason to do otherwise. There is also ongoing restructuring in the ARM Linux kernel to allow running the same kernel binary on multiple platforms. While there is still a lot of work to be done, you should assume that we will finish it before you see lots of users in production, there is no need to plan for the current one-kernel-per-board case. > > Ok. It would of course still be possible to agree on an argument passing > > convention so that we can share the macros used to issue the hcalls, > > even if the individual commands are all different. > > I think it likely that we can all agree on a common calling convention > for N-argument hypercalls. It doubt there are that many useful choices > with conflicting requirements yet strongly compelling advantages. Exactly. I think it's only lack of communication that has resulted in different interfaces for each hypervisor on the other architectures. KVM and Xen at least both fall into the single-return-value category, so we should be able to agree on a calling conventions. KVM does not have an hcall API on ARM yet, and I see no reason not to use the same implementation that you have in the Xen guest. Stefano, can you split out the generic parts of your asm/xen/hypercall.h file into a common asm/hypercall.h and submit it for review to the arm kernel list? Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions Date: Wed, 30 Nov 2011 18:15:01 +0000 Message-ID: <201111301815.01297.arnd@arndb.de> References: <201111301432.54463.arnd@arndb.de> <1322670473.31810.129.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org" , "linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org" , Pawel Moll , "kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "android-virt-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org" , "embeddedxen-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" To: Ian Campbell Return-path: In-Reply-To: <1322670473.31810.129.camel-o4Be2W7LfRlXesXXhkcM7miJhflN2719@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linaro-dev-bounces-cunTk1MwBs8s++Sfvej+rw@public.gmane.org Errors-To: linaro-dev-bounces-cunTk1MwBs8s++Sfvej+rw@public.gmane.org List-Id: kvm.vger.kernel.org On Wednesday 30 November 2011, Ian Campbell wrote: > On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote: > > On Wednesday 30 November 2011, Ian Campbell wrote: > > What I suggested to the KVM developers is to start out with the > > vexpress platform, but then generalize it to the point where it fits > > your needs. All hardware that one expects a guest to have (GIC, timer, > > ...) will still show up in the same location as on a real vexpress, > > while anything that makes no sense or is better paravirtualized (LCD, > > storage, ...) just becomes optional and has to be described in the > > device tree if it's actually there. > > That's along the lines of what I was thinking as well. > > The DT contains the address of GIC, timer etc as well right? So at least > in principal we needn't provide e.g. the GIC at the same address as any > real platform but in practice I expect we will. Yes. > In principal we could also offer the user options as to which particular > platform a guest looks like. At least when using a qemu based simulation. Most platforms have some characteristics that are not meaningful in a classic virtualization scenario, but it would certainly be helpful to use the virtualization extensions to run a kernel that was built for a particular platform faster than with pure qemu, when you want to test that kernel image. It has been suggested in the past that it would be nice to run the guest kernel built for the same platform as the host kernel by default, but I think it would be much better to have just one platform that we end up using for guests on any host platform, unless there is a strong reason to do otherwise. There is also ongoing restructuring in the ARM Linux kernel to allow running the same kernel binary on multiple platforms. While there is still a lot of work to be done, you should assume that we will finish it before you see lots of users in production, there is no need to plan for the current one-kernel-per-board case. > > Ok. It would of course still be possible to agree on an argument passing > > convention so that we can share the macros used to issue the hcalls, > > even if the individual commands are all different. > > I think it likely that we can all agree on a common calling convention > for N-argument hypercalls. It doubt there are that many useful choices > with conflicting requirements yet strongly compelling advantages. Exactly. I think it's only lack of communication that has resulted in different interfaces for each hypervisor on the other architectures. KVM and Xen at least both fall into the single-return-value category, so we should be able to agree on a calling conventions. KVM does not have an hcall API on ARM yet, and I see no reason not to use the same implementation that you have in the Xen guest. Stefano, can you split out the generic parts of your asm/xen/hypercall.h file into a common asm/hypercall.h and submit it for review to the arm kernel list? Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752010Ab1K3SPa (ORCPT ); Wed, 30 Nov 2011 13:15:30 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]:63925 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751279Ab1K3SP1 (ORCPT ); Wed, 30 Nov 2011 13:15:27 -0500 From: Arnd Bergmann To: Ian Campbell Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions Date: Wed, 30 Nov 2011 18:15:01 +0000 User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; ) Cc: Stefano Stabellini , "xen-devel@lists.xensource.com" , "linaro-dev@lists.linaro.org" , Pawel Moll , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "android-virt@lists.cs.columbia.edu" , "embeddedxen-devel@lists.sourceforge.net" , "linux-arm-kernel@lists.infradead.org" References: <201111301432.54463.arnd@arndb.de> <1322670473.31810.129.camel@zakaz.uk.xensource.com> In-Reply-To: <1322670473.31810.129.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201111301815.01297.arnd@arndb.de> X-Provags-ID: V02:K0:0QF1cQvBrkFixJKucsdEWFs++J4ZdGCXd6xZLH0sUdP 21sqNZwWW2YwtvqbQU2Vs+iQ4BgIvZVvo/jsjy2ecSHgQveLPk Tjz7jIsFzmcDdfNKxCi3i0SWyVisDmPvpwSOiWUs3+qYfYotgY SzSFXIT4rrefbhicv0lGTuxjkL8QLX8Rt+d+4AMJRi2qoyJNZk hjHtyd8Tvl4d8Pr4lm8BaAqnC29b/z/Ofz4aoYhjXHxQaVhYP1 sa9U+vGtMYMM4pgmbuMUug7CKpm50HgsgC8Pyanp79QMu5i4kc GJLL0GRZ3vW3xUL2hHubZN0QyoqMEefw/Q7qX0RdMYvcLoHidJ nlIloH22xJUm+hwTXhNE= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 30 November 2011, Ian Campbell wrote: > On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote: > > On Wednesday 30 November 2011, Ian Campbell wrote: > > What I suggested to the KVM developers is to start out with the > > vexpress platform, but then generalize it to the point where it fits > > your needs. All hardware that one expects a guest to have (GIC, timer, > > ...) will still show up in the same location as on a real vexpress, > > while anything that makes no sense or is better paravirtualized (LCD, > > storage, ...) just becomes optional and has to be described in the > > device tree if it's actually there. > > That's along the lines of what I was thinking as well. > > The DT contains the address of GIC, timer etc as well right? So at least > in principal we needn't provide e.g. the GIC at the same address as any > real platform but in practice I expect we will. Yes. > In principal we could also offer the user options as to which particular > platform a guest looks like. At least when using a qemu based simulation. Most platforms have some characteristics that are not meaningful in a classic virtualization scenario, but it would certainly be helpful to use the virtualization extensions to run a kernel that was built for a particular platform faster than with pure qemu, when you want to test that kernel image. It has been suggested in the past that it would be nice to run the guest kernel built for the same platform as the host kernel by default, but I think it would be much better to have just one platform that we end up using for guests on any host platform, unless there is a strong reason to do otherwise. There is also ongoing restructuring in the ARM Linux kernel to allow running the same kernel binary on multiple platforms. While there is still a lot of work to be done, you should assume that we will finish it before you see lots of users in production, there is no need to plan for the current one-kernel-per-board case. > > Ok. It would of course still be possible to agree on an argument passing > > convention so that we can share the macros used to issue the hcalls, > > even if the individual commands are all different. > > I think it likely that we can all agree on a common calling convention > for N-argument hypercalls. It doubt there are that many useful choices > with conflicting requirements yet strongly compelling advantages. Exactly. I think it's only lack of communication that has resulted in different interfaces for each hypervisor on the other architectures. KVM and Xen at least both fall into the single-return-value category, so we should be able to agree on a calling conventions. KVM does not have an hcall API on ARM yet, and I see no reason not to use the same implementation that you have in the Xen guest. Stefano, can you split out the generic parts of your asm/xen/hypercall.h file into a common asm/hypercall.h and submit it for review to the arm kernel list? Arnd