Re: HVMLite / PVHv2 - using x86 EFI boot entry

["Luis R. Rodriguez" <mcgrof@kernel.org>]

On Thu, Apr 14, 2016 at 10:42:15AM +0100, George Dunlap wrote:
> On 13/04/16 19:54, Luis R. Rodriguez wrote:
> > On Wed, Apr 13, 2016 at 11:05:00AM +0100, George Dunlap wrote:
> >> On Tue, Apr 12, 2016 at 11:12 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> >>> 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.
> >>
> >> I'm not sure how this is relevant to anything.
> > 
> > You brought DT as a reason why ARM was able to use the native point.
> > I'm clarifying DT has nothing to do as a restriction on x86.
> 
> No, DT isn't the reason Xen is able to use the native entry point on
> ARM.  The reason is, to quote myself: "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 that's three things:
> 1. DT is available to be used
> 2. DT is expected as the main thing that entry point accepts
> 3. There are no assumptions about what hardware is or is not present in
> the system
> 4. Everything that needs to be communicated about what is or is not
> present can be passed in DT.
> 
> Are #2, #3, and #4 true on x86?  If not then #1 is irrelevant.

2) Obviously not, but it can be used.
3) We're getting close to that, see the platform legacy work [0],
   that should help us mesh things into a generic form that we
   didn't have before. There may be others, as is being discussed.
   If you have other ideas now would be great to hear of them.
4) we have ACPI to fill in the gaps these days for not only x86
   but also ARM, as such I think it makes sense to only use DT
   when it makes sense and to standardize on ACPI when possible

[0] http://lkml.kernel.org/r/1460592286-300-1-git-send-email-mcgrof@kernel.org

> [snip from another thread]
> 
> > One. CE4100.
> >
> > arch/x86/platform/ce4100/falconfalls.dt
> 
> You CC'd me on some patches related to that.  I don't know anything
> about the code, but it looked like CE4100 is a subarch, and in response
> to that thread Ingo specifically asked you to add a comment saying
> basically "Don't add any more subarches".

Yeap!

> And not only that, but the ugly, nasty legacy PV boot path we're trying
> to get rid of IS ALSO A SUBARCH.  So instead of a quick stub with an
> extra EFI flag, you're proposing we consider add yet another Xen PV subarch?

A little while ago I brought that up as a possibility, given that the
semantics of use of the subarch were also loose... hence the discussion
over that, and now a patch that helps clarify the use as you were
Cc'd on.

What's been decided is that we should not extend the subarch, however
if we need a hypervisor type that's a separate topic and we would need
to address that separately. Its possible. I find it sensible specially if
the goal is to avoid more sporadic entries on Linux and to help with
early boot semantics / addressing dead code prospects.

EFI is another option which already has code and an entry and its
why I've asked us to consider it. So we should probably not really
try to look at adding a hypervisor type until we've really decided
that EFI is a no go at all and makes no sense.

IMHO we should add new entries to x86 linux only as a last resort measure.

> >> What we're talking about is how to get from Xen to a point in the
> >> Linux kernel where everything can Just Work.  The proposed feature is
> >> a mini trampoline that (as I understand it):
> >> 1. Tells Xen where to jump to (via ELF note)
> >> 2. Sets up some basic modes and pagetables and then jumps to the zero
> >> page so Linux can just carry on.
> > 
> > Right, and the my goal is to see to it we do enough homework to
> > ensure we reviewed all possibilities to share as much code as possible
> > already and looked at all options before saying we certainly need yet
> > another entry point. I am not convinced yet this has been done.
> 
> I think we have different ideas about what an appropriate amount of
> homework is. :-)  Everything you've put forward has been given
> consideration and judged unlikely to be promising;

That's fine I'm not afraid of suggestions to be discarded, my goal
is to evaluate all possibilities from an engineering point of
view, and then make decisions.

> and your suggestions for further possibilities (like this one) keep getting
> more and more obviously unsuitable.

Really ? If it wasn't for me looking into the paravirt crap you'd
end up likely with some other semantic mess. If you'd really like
me to stop chiming in let me know and I'll look away form Xen for
good like others have.

> We shouldn't be required to actually post code
> for every single other option just to prove how ugly they are,
> particularly when there's nothing particularly wrong with the code we have.

I'm not asking that. I'm asking for an engineering evaluation. That's very
different. I am going to the Xen Hackathon after all as well, not sure what
else to tell you to show you I'm only after the best engineering solution and
it seems we could do much better here.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel