public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: "George Dunlap" <george.dunlap@citrix.com>,
	"Matt Fleming" <matt@codeblueprint.co.uk>,
	"Michael Chang" <MChang@suse.com>,
	"Julien Grall" <julien.grall@arm.com>,
	"Jan Beulich" <JBeulich@suse.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Daniel Kiper" <daniel.kiper@oracle.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"Vojtěch Pavlík" <vojtech@suse.cz>, "Gary Lin" <GLin@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	"Jeffrey Cheung" <JCheung@suse.com>,
	"Charles Arndol" <carnold@suse.com>,
	"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
	"Jim Fehlig" <jfehlig@suse.com>, joeyli <jlee@suse.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Andy Lutomirski" <luto@amacapital.net>,
	"David Vrabel" <david.vrabel@citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Takashi Iwai" <tiwai@suse.de>,
	jeffm@suse.com, torvalds@linux-foundation.org,
	"Julien Grall" <julien.grall@linaro.org>
Subject: Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry
Date: Wed, 13 Apr 2016 00:12:25 +0200	[thread overview]
Message-ID: <20160412221225.GN1990@wotan.suse.de> (raw)
In-Reply-To: <20160408215854.GU1990@wotan.suse.de>

On Fri, Apr 08, 2016 at 11:58:54PM +0200, Luis R. Rodriguez wrote:
> On Fri, Apr 08, 2016 at 03:16:14PM +0100, George Dunlap wrote:
> > On 07/04/16 19:51, Luis R. Rodriguez wrote:
> > > While Andrew's position is right in that perhaps only Xen tools have to deal
> > > with the HVMLite specific entry, it would also still mean diverging from ARM's
> > > own EFI entry only position, which I'd like to clarify that ARM has no custom
> > > Xen entry, we should strive to match that. Anything far from that to me really
> > > deserves an explanation, specially if we are going to argue that HVMLite is
> > > the best that x86 Xen can do.
> > > 
> > > Ultimately unifying entry approaches for Xen in a streamlined fashion seems
> > > like a sensible thing to strive for. Anything we push in the other direction,
> > > as small as it can be, should deserve at least a 'hey, wait a minute'...
> > 
> > Quick factual correction here.
> > 
> > "Since ARM guests only use the EFI entry point, x86 guests should also
> > only use the EFI entry point" is certainly a reasonable argument to make.
> > 
> > However, dom0 on ARM does not use the EFI entry point.  When starting
> > dom0, Xen uses the native entry point (the one that UBoot uses) and
> > hands dom0 a device-tree node.  The reason this is possible on ARM is
> > that there are no assumptions made about what hardware is or is not
> > present on the system -- everything that needs to be communicated about
> > what is or is not present can be passed in DT.
> > 
> > So it is incorrect to say that ARM has an "EFI entry only" position.
> > 
> > (On ACPI systems, it does apparently generate some UEFI informational
> > tables, which it passes to the dom0 kernel via DT; and the kernel
> > unpacks and puts in the right place.  Normal Xen ARM guests can use EFI,
> > but that's because we start OVMF in the guest context to provide the EFI
> > services.  These may be where the idea that ARM guests use only the UEFI
> > entry point came from.)
> > 
> > Obviously it would be nice if we could use the native entry point on x86
> > as well, but there's decades of legacy hardware and backwards
> > compatibility to deal with there.
> 
> OK thanks for the clarification -- still no custom entries for Xen!
> We should strive for that, at the very least.
> 
> You do have a point about the legacy stuff. There are two options there:
> 
>   * Fold legacy support under HVMLite -- which seems to be what we
>     currently want to do (we should evaluate the implications and
>     requirements here for that); or
> 
>   * Leave legacy stuff on the old PV path; this may be something to
>     bring to the table if we had in place a proactive solution to
>     avoid further fallout from the architecture of the huge differences
>     on the entries. The work I'm doing should help with that. (We should
>     also evaluate the implications and requirements here for that as
>     well).

Also, x86 does have a history of short DT use. Just pointing that its there as
an option as well. I'll Cc you on some thread about that.

  Luis

  reply	other threads:[~2016-04-12 22:12 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-06  2:40 HVMLite / PVHv2 - using x86 EFI boot entry Luis R. Rodriguez
2016-04-06  9:40 ` David Vrabel
2016-04-08 20:40   ` Luis R. Rodriguez
2016-04-11  5:12     ` Juergen Gross
2016-04-12 21:02       ` Andy Lutomirski
2016-04-13  9:02         ` Roger Pau Monné
2016-04-13 10:15           ` Matt Fleming
2016-04-13 10:40             ` Matt Fleming
2016-04-13 11:12             ` [Xen-devel] " George Dunlap
2016-04-13 11:59             ` Roger Pau Monné
2016-04-15 22:53               ` Matt Fleming
2016-04-13 18:29       ` Luis R. Rodriguez
     [not found]         ` <20160413185629.GA7501@char.us.oracle.com>
2016-04-13 20:40           ` [Xen-devel] " Luis R. Rodriguez
     [not found]             ` <20160413210801.GC5962@char.us.oracle.com>
2016-04-13 22:23               ` Luis R. Rodriguez
2016-04-14  1:01                 ` Konrad Rzeszutek Wilk
2016-04-14 18:40                   ` Luis R. Rodriguez
2016-04-14 19:56                     ` Konrad Rzeszutek Wilk
2016-04-14 20:56                       ` Luis R. Rodriguez
2016-04-15  2:02                         ` Konrad Rzeszutek Wilk
2016-04-15 17:08                           ` Luis R. Rodriguez
2016-04-15 10:06                         ` Julien Grall
2016-04-15 14:55                           ` Luis R. Rodriguez
2016-04-15 18:44                             ` Stefano Stabellini
2016-04-06 11:07 ` George Dunlap
2016-04-06 15:02   ` Matt Fleming
     [not found]     ` <20160406160516.GC23684@char.us.oracle.com>
     [not found]       ` <20160406162347.GD23684@char.us.oracle.com>
2016-04-08 21:53         ` Luis R. Rodriguez
2016-04-13 10:03     ` Roger Pau Monné
2016-04-13 10:21       ` Matt Fleming
2016-04-07 18:51   ` Luis R. Rodriguez
2016-04-08 14:16     ` George Dunlap
2016-04-08 21:58       ` Luis R. Rodriguez
2016-04-12 22:12         ` Luis R. Rodriguez [this message]
2016-04-13 10:05           ` George Dunlap
2016-04-13 18:54             ` Luis R. Rodriguez
2016-04-14  9:42               ` George Dunlap
2016-04-14 19:59                 ` Luis R. Rodriguez
2016-04-13 10:25           ` Roger Pau Monné
2016-04-13 19:10             ` Luis R. Rodriguez
2016-04-13  9:54         ` Roger Pau Monné
2016-04-13 18:50           ` Luis R. Rodriguez
     [not found]             ` <20160413190226.GB7501@char.us.oracle.com>
2016-04-13 19:14               ` Luis R. Rodriguez
     [not found]                 ` <20160413192223.GA19026@char.us.oracle.com>
2016-04-13 20:01                   ` Luis R. Rodriguez
     [not found]                     ` <20160413201120.GA29797@char.us.oracle.com>
2016-04-13 20:35                       ` Luis R. Rodriguez
2016-04-14 10:13                 ` George Dunlap
2016-04-13 15:44     ` George Dunlap
2016-04-13 19:52       ` Luis R. Rodriguez
2016-04-14  9:53         ` George Dunlap
2016-04-14 19:44           ` Luis R. Rodriguez
2016-04-14 20:38             ` Konrad Rzeszutek Wilk
2016-04-14 21:12               ` Luis R. Rodriguez
2016-04-15  2:14                 ` Konrad Rzeszutek Wilk
2016-04-15  5:50             ` Juergen Gross
2016-04-15 15:24               ` Luis R. Rodriguez
2016-04-15  9:59             ` George Dunlap
2016-04-15 15:30               ` Luis R. Rodriguez
2016-04-15 16:03                 ` George Dunlap
2016-04-15 17:17                   ` Luis R. Rodriguez
2016-04-06 11:11 ` Daniel Kiper
2016-04-07 19:12   ` Luis R. Rodriguez
2016-04-09 17:02   ` Luis R. Rodriguez

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=20160412221225.GN1990@wotan.suse.de \
    --to=mcgrof@kernel.org \
    --cc=GLin@suse.com \
    --cc=JBeulich@suse.com \
    --cc=JCheung@suse.com \
    --cc=MChang@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=carnold@suse.com \
    --cc=daniel.kiper@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=hpa@zytor.com \
    --cc=jeffm@suse.com \
    --cc=jfehlig@suse.com \
    --cc=jgross@suse.com \
    --cc=jlee@suse.com \
    --cc=julien.grall@arm.com \
    --cc=julien.grall@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=matt@codeblueprint.co.uk \
    --cc=roger.pau@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tiwai@suse.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vojtech@suse.cz \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.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