From: Dave Martin <dave.martin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@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>,
Ian Campbell
<Ian.Campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>,
"arnd-r2nGTMty4D4@public.gmane.org"
<arnd-r2nGTMty4D4@public.gmane.org>,
"konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org"
<konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
"catalin.marinas-5wv7dgnIgG8@public.gmane.org"
<catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
"Tim (Xen.org)" <tim-LM2mM/qkH7s@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
David Vrabel
<david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v3 06/25] docs: Xen ARM DT bindings
Date: Thu, 13 Sep 2012 11:29:38 +0100 [thread overview]
Message-ID: <20120913102938.GB2470@linaro.org> (raw)
In-Reply-To: <50514634.3080303-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Sep 12, 2012 at 09:34:28PM -0500, Rob Herring wrote:
> On 09/12/2012 01:14 PM, Stefano Stabellini wrote:
> > On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> >> On Tue, 28 Aug 2012, Rob Herring wrote:
> >>> You should look at ePAPR 1.1 which defines hypervisor related bindings.
> >>> While it is a PPC doc, we should reuse or extend what makes sense.
> >>>
> >>> See section 7.5:
> >>>
> >>> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
> >>
> >> Thanks for the link, I wasn't aware of ePAPR.
> >>
> >> The hypervisor node defined by ePAPR is not very different from what I
> >> am proposing. Should I try to be compatible with the hypervisor
> >> specification above (as in compatible = "epapr,hypervisor-1.1")?
> >> Or should I just use it as a reference for my own specification?
> >>
> >> Personally I would rather avoid full compatibility with ePAPR.
> >
> > In particular reading section 7.5, these are the required properties of
> > the ePAPR hypervisor node:
> >
> > - compatible = "epapr,hypervisor-1.1"
> > compared to what I am proposing, it is laking information about what
> > hypervisor we are talking about (xen, kvm, vmware, etc) and the version
> > of the ABI (xen-4.2).
>
> compatible properties are often changed. If we do deviate on the rest of
> the binding, then it needs to be different.
>
> Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor"
> doesn't even appear in the kernel.
>
> We also perhaps have to consider the possibility of Xen on PowerPC. Then
> alignment is more important.
>
> > - hcall-instructions
> > potentially interesting, but given that for Xen we are quite happy with
> > HVC, we are not going to add any secondary hypercall mechanisms,
> > therefore at the moment it would just result in a BUG if the specified
> > hcall instruction is != HVC. Besides if somebody else wanted to
> > implemented the Xen hypercall interface in a different way they could
> > just reimplement the hypercall wrappers, that would be easier than
> > trying to do it with this property.
>
> It's really about the parameters passed with the HVC. The ePAPR may be a
> good model for defining this. Just grepping "hypervisor" under
> arch/powerpc, it's pretty clear hypervisor support happened first and
> the ePAPR came second. Hopefully we can avoid that for ARM.
Do you think it's feasible to standardise on some interoperable ABI for
kvm and Xen? This sounds pretty optimistic, but I'm not aware of all
the technicalities, or what possible third-party hypervisors are out
there.
If we could do it, it would be good. But I have my doubts about the
feasibility and the benefits. If different hypervisors are significantly
imcompatible, then having a common low-level ABI doesn't help all that
much.
Cheers
---Dave
next prev parent reply other threads:[~2012-09-13 10:29 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 15:33 [PATCH v3 00/23] Introduce Xen support on ARM Stefano Stabellini
2012-08-16 15:35 ` [PATCH v3 01/25] arm: initial Xen support Stefano Stabellini
2012-08-16 15:35 ` [PATCH v3 03/25] xen/arm: page.h definitions Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 11/25] xen: do not compile manage, balloon, pci, acpi and cpu_hotplug on ARM Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 18/25] xen: allow privcmd for HVM guests Stefano Stabellini
[not found] ` <alpine.DEB.2.02.1208161618550.4850-7Z66fg9igcxYtxbxJUhB2Dgeux46jI+i@public.gmane.org>
2012-08-16 15:35 ` [PATCH v3 02/25] xen/arm: hypercalls Stefano Stabellini
2012-08-16 15:35 ` [PATCH v3 04/25] xen/arm: sync_bitops Stefano Stabellini
2012-08-16 15:35 ` [PATCH v3 05/25] xen/arm: empty implementation of grant_table arch specific functions Stefano Stabellini
2012-08-16 15:35 ` [PATCH v3 06/25] docs: Xen ARM DT bindings Stefano Stabellini
2012-08-27 23:03 ` Rob Herring
[not found] ` <503BFCD8.5090804-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-09-12 17:07 ` Stefano Stabellini
[not found] ` <alpine.DEB.2.02.1208281823270.15568-7Z66fg9igcxYtxbxJUhB2Dgeux46jI+i@public.gmane.org>
2012-09-12 18:14 ` Stefano Stabellini
2012-09-13 2:34 ` Rob Herring
[not found] ` <50514634.3080303-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-09-13 10:29 ` Dave Martin [this message]
[not found] ` <20120913102938.GB2470-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-09-13 11:19 ` Stefano Stabellini
2012-09-13 11:33 ` Stefano Stabellini
2012-09-13 10:26 ` Dave Martin
2012-09-13 11:12 ` Stefano Stabellini
2012-08-16 15:35 ` [PATCH v3 07/25] xen/arm: Xen detection and shared_info page mapping Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 08/25] xen/arm: Introduce xen_pfn_t for pfn and mfn types Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 09/25] xen/arm: Introduce xen_ulong_t for unsigned long Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 10/25] xen/arm: compile and run xenbus Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 12/25] xen/arm: introduce CONFIG_XEN on ARM Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 13/25] xen/arm: get privilege status Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 14/25] xen/arm: initialize grant_table on ARM Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 15/25] xen/arm: receive Xen events " Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 16/25] xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 17/25] xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 19/25] xen/arm: compile blkfront and blkback Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 20/25] xen/arm: compile netback Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 21/25] arm/v2m: initialize arch_timers even if v2m_timer is not present Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 22/25] xen/arm: use the __HVC macro Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 23/25] xen: missing includes Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 24/25] xen: update xen_add_to_physmap interface Stefano Stabellini
2012-08-16 15:36 ` [PATCH v3 25/25] [HACK] xen/arm: implement xen_remap_domain_mfn_range Stefano Stabellini
2012-09-13 17:15 ` [PATCH v3 00/23] Introduce Xen support on ARM Stefano Stabellini
2012-10-24 15:26 ` [PATCH RESEND] xen/arm: use the __HVC macro Stefano Stabellini
2012-11-05 10:58 ` Dave Martin
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=20120913102938.GB2470@linaro.org \
--to=dave.martin-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
--cc=Ian.Campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=david.vrabel-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=tim-LM2mM/qkH7s@public.gmane.org \
--cc=xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).