All of lore.kernel.org
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [Android-virt] [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
Date: Thu, 1 Dec 2011 15:10:43 +0000	[thread overview]
Message-ID: <20111201151043.GG27394@arm.com> (raw)
In-Reply-To: <1322735197.31810.191.camel@zakaz.uk.xensource.com>

On Thu, Dec 01, 2011 at 10:26:37AM +0000, Ian Campbell wrote:
> On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> > On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > > 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?
> > 
> > Sure, I can do that.
> > Usually the hypercall calling convention is very hypervisor specific,
> > but if it turns out that we have the same requirements I happy to design
> > a common interface.
> 
> I expect the only real decision to be made is hypercall page vs. raw hvc
> instruction.
> 
> The page was useful on x86 where there is a variety of instructions
> which could be used (at least for PV there was systenter/syscall/int, I
> think vmcall instruction differs between AMD and Intel also) and gives
> some additional flexibility. It's hard to predict but I don't think I'd
> expect that to be necessary on ARM.
> 
> Another reason for having a hypercall page instead of a raw instruction
> might be wanting to support 32 bit guests (from ~today) on a 64 bit
> hypervisor in the future and perhaps needing to do some shimming/arg
> translation. It would be better to aim for having the interface just be
> 32/64 agnostic but mistakes do happen.

Given the way register banking is done on AArch64, issuing an HVC on a
32-bit guest OS doesn't require translation on a 64-bit hypervisor. We
have a similar implementation at the SVC level (for 32-bit user apps on
a 64-bit kernel), the only modification was where a 32-bit SVC takes a
64-bit parameter in two separate 32-bit registers, so packing needs to
be done in a syscall wrapper.

I'm not closely involved with any of the Xen or KVM work but I would
vote for using HVC than a hypercall page.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
To: Ian Campbell <Ian.Campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
Cc: "xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org"
	<xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org>,
	"linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org"
	<linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	"android-virt-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org"
	<android-virt-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org>,
	"kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"embeddedxen-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org"
	<embeddedxen-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [Android-virt] [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
Date: Thu, 1 Dec 2011 15:10:43 +0000	[thread overview]
Message-ID: <20111201151043.GG27394@arm.com> (raw)
In-Reply-To: <1322735197.31810.191.camel-o4Be2W7LfRlXesXXhkcM7miJhflN2719@public.gmane.org>

On Thu, Dec 01, 2011 at 10:26:37AM +0000, Ian Campbell wrote:
> On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> > On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > > 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?
> > 
> > Sure, I can do that.
> > Usually the hypercall calling convention is very hypervisor specific,
> > but if it turns out that we have the same requirements I happy to design
> > a common interface.
> 
> I expect the only real decision to be made is hypercall page vs. raw hvc
> instruction.
> 
> The page was useful on x86 where there is a variety of instructions
> which could be used (at least for PV there was systenter/syscall/int, I
> think vmcall instruction differs between AMD and Intel also) and gives
> some additional flexibility. It's hard to predict but I don't think I'd
> expect that to be necessary on ARM.
> 
> Another reason for having a hypercall page instead of a raw instruction
> might be wanting to support 32 bit guests (from ~today) on a 64 bit
> hypervisor in the future and perhaps needing to do some shimming/arg
> translation. It would be better to aim for having the interface just be
> 32/64 agnostic but mistakes do happen.

Given the way register banking is done on AArch64, issuing an HVC on a
32-bit guest OS doesn't require translation on a 64-bit hypervisor. We
have a similar implementation at the SVC level (for 32-bit user apps on
a 64-bit kernel), the only modification was where a 32-bit SVC takes a
64-bit parameter in two separate 32-bit registers, so packing needs to
be done in a syscall wrapper.

I'm not closely involved with any of the Xen or KVM work but I would
vote for using HVC than a hypercall page.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, Pawel Moll <Pawel.Moll@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org" 
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" 
	<android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net" 
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Android-virt] [Embeddedxen-devel] [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
Date: Thu, 1 Dec 2011 15:10:43 +0000	[thread overview]
Message-ID: <20111201151043.GG27394@arm.com> (raw)
In-Reply-To: <1322735197.31810.191.camel@zakaz.uk.xensource.com>

On Thu, Dec 01, 2011 at 10:26:37AM +0000, Ian Campbell wrote:
> On Wed, 2011-11-30 at 18:32 +0000, Stefano Stabellini wrote:
> > On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > > 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?
> > 
> > Sure, I can do that.
> > Usually the hypercall calling convention is very hypervisor specific,
> > but if it turns out that we have the same requirements I happy to design
> > a common interface.
> 
> I expect the only real decision to be made is hypercall page vs. raw hvc
> instruction.
> 
> The page was useful on x86 where there is a variety of instructions
> which could be used (at least for PV there was systenter/syscall/int, I
> think vmcall instruction differs between AMD and Intel also) and gives
> some additional flexibility. It's hard to predict but I don't think I'd
> expect that to be necessary on ARM.
> 
> Another reason for having a hypercall page instead of a raw instruction
> might be wanting to support 32 bit guests (from ~today) on a 64 bit
> hypervisor in the future and perhaps needing to do some shimming/arg
> translation. It would be better to aim for having the interface just be
> 32/64 agnostic but mistakes do happen.

Given the way register banking is done on AArch64, issuing an HVC on a
32-bit guest OS doesn't require translation on a 64-bit hypervisor. We
have a similar implementation at the SVC level (for 32-bit user apps on
a 64-bit kernel), the only modification was where a 32-bit SVC takes a
64-bit parameter in two separate 32-bit registers, so packing needs to
be done in a syscall wrapper.

I'm not closely involved with any of the Xen or KVM work but I would
vote for using HVC than a hypercall page.

-- 
Catalin

  parent reply	other threads:[~2011-12-01 15:10 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-29 14:53 [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions Stefano Stabellini
2011-11-29 14:53 ` Stefano Stabellini
2011-11-29 14:53 ` Stefano Stabellini
2011-11-29 14:53 ` Stefano Stabellini
2011-11-29 21:29 ` Arnd Bergmann
2011-11-29 21:29   ` Arnd Bergmann
     [not found]   ` <201111292129.20444.arnd-r2nGTMty4D4@public.gmane.org>
2011-11-30  4:42     ` Anup Patel
2011-11-30 11:41       ` Stefano Stabellini
2011-11-30 11:41         ` Stefano Stabellini
2011-11-30 11:41         ` Stefano Stabellini
2011-11-30  4:42   ` Anup Patel
2011-11-30 11:39   ` Stefano Stabellini
2011-11-30 11:39     ` Stefano Stabellini
2011-11-30 11:39     ` Stefano Stabellini
2011-11-30 13:03     ` Arnd Bergmann
2011-11-30 13:03       ` Arnd Bergmann
2011-11-30 13:25       ` [Xen-devel] " Ian Campbell
2011-11-30 13:25       ` Ian Campbell
2011-11-30 13:25         ` Ian Campbell
2011-11-30 14:32         ` Arnd Bergmann
2011-11-30 14:32         ` Arnd Bergmann
2011-11-30 14:32           ` Arnd Bergmann
2011-11-30 14:32           ` Arnd Bergmann
2011-11-30 14:51           ` Pawel Moll
2011-11-30 14:51           ` Pawel Moll
2011-11-30 14:51             ` Pawel Moll
2011-11-30 16:27           ` Ian Campbell
2011-11-30 16:27             ` Ian Campbell
2011-11-30 16:27             ` Ian Campbell
2011-11-30 18:15             ` Arnd Bergmann
2011-11-30 18:15               ` Arnd Bergmann
2011-11-30 18:15               ` Arnd Bergmann
2011-11-30 18:32               ` [Embeddedxen-devel] " Stefano Stabellini
2011-11-30 18:32                 ` Stefano Stabellini
2011-11-30 18:32                 ` Stefano Stabellini
2011-12-01 10:26                 ` Ian Campbell
2011-12-01 10:26                   ` Ian Campbell
2011-12-01 10:26                   ` Ian Campbell
2011-12-01 15:10                   ` [Android-virt] " Catalin Marinas
2011-12-01 15:10                   ` Catalin Marinas [this message]
2011-12-01 15:10                     ` Catalin Marinas
2011-12-01 15:10                     ` Catalin Marinas
2011-12-01 15:42                     ` Arnd Bergmann
2011-12-01 15:42                       ` Arnd Bergmann
2011-12-01 15:42                       ` Arnd Bergmann
2011-12-01 16:02                       ` Catalin Marinas
2011-12-01 16:02                         ` Catalin Marinas
2011-12-01 16:02                         ` Catalin Marinas
2011-12-01 16:44                         ` Arnd Bergmann
2011-12-01 16:44                           ` Arnd Bergmann
2011-12-01 16:44                           ` Arnd Bergmann
2011-12-01 16:57                           ` Catalin Marinas
2011-12-01 16:57                             ` Catalin Marinas
2011-12-01 16:57                             ` Catalin Marinas
2011-12-01 15:52                     ` Ian Campbell
2011-12-01 15:52                       ` Ian Campbell
2011-12-01 15:52                       ` Ian Campbell
2011-12-01 15:12                   ` Stefano Stabellini
2011-12-01 15:12                     ` Stefano Stabellini
2011-12-01 15:12                     ` Stefano Stabellini
2011-12-01 10:34               ` Ian Campbell
2011-12-01 10:34                 ` Ian Campbell
2011-11-30 18:15             ` Arnd Bergmann
2011-11-30 13:03     ` Arnd Bergmann
2011-11-30 14:11     ` Catalin Marinas
2011-11-30 14:11       ` Catalin Marinas
2011-11-30 14:20       ` Stefano Stabellini
2011-11-30 14:20         ` Stefano Stabellini
2011-11-30 14:20         ` Stefano Stabellini
2011-12-16 15:43       ` [Xen-devel] " David Vrabel
2011-12-16 15:43         ` David Vrabel
2011-12-16 16:54         ` Catalin Marinas
2011-12-16 16:54           ` Catalin Marinas
2011-12-16 17:38           ` David Vrabel
2011-12-16 17:38             ` David Vrabel
2011-12-16 17:47             ` Catalin Marinas
2011-12-16 17:47               ` Catalin Marinas
2011-11-30 14:11     ` Catalin Marinas
2011-11-29 21:29 ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111201151043.GG27394@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.