Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1372156 > unrolled thread

HVMLite / PVHv2 - using x86 EFI boot entry

Back to article view | Back to linux.kernel

Contents

  HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-06 04:50 +0200
    Re: HVMLite / PVHv2 - using x86 EFI boot entry David Vrabel <david.vrabel@citrix.com> - 2016-04-06 11:50 +0200
      Re: HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-08 22:50 +0200
        Re: HVMLite / PVHv2 - using x86 EFI boot entry Juergen Gross <jgross@suse.com> - 2016-04-11 07:20 +0200
          Re: HVMLite / PVHv2 - using x86 EFI boot entry Andy Lutomirski <luto@amacapital.net> - 2016-04-12 23:10 +0200
            Re: HVMLite / PVHv2 - using x86 EFI boot entry Roger Pau Monné <roger.pau@citrix.com> - 2016-04-13 11:10 +0200
              Re: HVMLite / PVHv2 - using x86 EFI boot entry Matt Fleming <matt@codeblueprint.co.uk> - 2016-04-13 12:20 +0200
                Re: HVMLite / PVHv2 - using x86 EFI boot entry Matt Fleming <matt@codeblueprint.co.uk> - 2016-04-13 12:50 +0200
                Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry George Dunlap <george.dunlap@citrix.com> - 2016-04-13 13:20 +0200
                Re: HVMLite / PVHv2 - using x86 EFI boot entry Roger Pau Monné <roger.pau@citrix.com> - 2016-04-13 14:00 +0200
          Re: HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-13 20:40 +0200
            Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-13 22:50 +0200
              Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-14 00:30 +0200
                Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> - 2016-04-14 03:10 +0200
                  Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-14 20:50 +0200
                    Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> - 2016-04-14 22:00 +0200
                      Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-14 23:00 +0200
                        Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> - 2016-04-15 04:10 +0200
                        Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Julien Grall <julien.grall@arm.com> - 2016-04-15 12:10 +0200
                          Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-15 17:00 +0200
    Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry George Dunlap <george.dunlap@citrix.com> - 2016-04-06 13:10 +0200
      Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Matt Fleming <matt@codeblueprint.co.uk> - 2016-04-06 17:10 +0200
        Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-09 00:00 +0200
        Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Roger Pau Monné <roger.pau@citrix.com> - 2016-04-13 12:10 +0200
          Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Matt Fleming <matt@codeblueprint.co.uk> - 2016-04-13 12:30 +0200
      Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@suse.com> - 2016-04-07 21:00 +0200
        Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry George Dunlap <george.dunlap@citrix.com> - 2016-04-08 16:20 +0200
          Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-09 00:00 +0200
            Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-13 00:20 +0200
              Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry George Dunlap <george.dunlap@citrix.com> - 2016-04-13 12:10 +0200
                Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-13 21:00 +0200
                  Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry George Dunlap <george.dunlap@citrix.com> - 2016-04-14 11:50 +0200
                    Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-14 22:00 +0200
              Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Roger Pau Monné <roger.pau@citrix.com> - 2016-04-13 12:30 +0200
                Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-13 21:20 +0200
            Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Roger Pau Monné <roger.pau@citrix.com> - 2016-04-13 12:00 +0200
              Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-13 21:00 +0200
                Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-13 21:20 +0200
                  Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-13 22:10 +0200
                    Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-13 22:40 +0200
                  Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry George Dunlap <george.dunlap@citrix.com> - 2016-04-14 12:20 +0200
        Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry George Dunlap <george.dunlap@citrix.com> - 2016-04-13 18:00 +0200
          Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-13 22:00 +0200
            Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry George Dunlap <george.dunlap@citrix.com> - 2016-04-14 12:00 +0200
              Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-14 21:50 +0200
                Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> - 2016-04-14 22:50 +0200
                  Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-14 23:20 +0200
                    Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> - 2016-04-15 04:20 +0200
                Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry Juergen Gross <jgross@suse.com> - 2016-04-15 08:00 +0200
                  Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-15 17:30 +0200
                Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry George Dunlap <george.dunlap@citrix.com> - 2016-04-15 12:00 +0200
                  Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-15 17:40 +0200
                    Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry George Dunlap <george.dunlap@citrix.com> - 2016-04-15 18:10 +0200
    Re: HVMLite / PVHv2 - using x86 EFI boot entry Daniel Kiper <daniel.kiper@oracle.com> - 2016-04-06 13:20 +0200
      Re: HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-07 21:20 +0200
      Re: HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-09 19:10 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#1378675 — Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On 13/04/16 20:14, Luis R. Rodriguez wrote:
> On Wed, Apr 13, 2016 at 03:02:26PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Wed, Apr 13, 2016 at 08:50:10PM +0200, Luis R. Rodriguez wrote:
>>> On Wed, Apr 13, 2016 at 11:54:29AM +0200, Roger Pau Monné wrote:
>>>> On Fri, Apr 08, 2016 at 11:58:54PM +0200, Luis R. Rodriguez wrote:
>>>>> 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
>>>>
>>>> I'm not following here. What does it mean to fold legacy support under 
>>>> HVMlite? HVMlite doesn't have any legacy hardware, and that's the issue when 
>>>> it comes to using native Linux entry points. Linux might expect some legacy 
>>>> PC hardware to be always present, which is not true for HVMlite.
>>>>
>>>> Could you please clarify this point?
>>>
>>> It seems there is a confusion on terms used. By folding legacy support under
>>> HVMLite I meant folding legacy PV path (classic PV with PV interfaces) under
>>> HVMlite.
>>
>> Ewww.
> 
> Probably a confusion again on terms, by the above I meant to say what you seem
> to be indicating below, which is to keep old PV guest support with PV interfaces
> using a new shiny entry.
> 
> Or are we really going to nuke full support for old PV guests ?

Just to be clear: In this case "support for old PV guests" really means,
"Support for running new versions of Linux in PV mode on old
(non-HVMLite-capable) hypervisors".  And yes, that is the plan: in 5
years' time, if you're still running Xen 4.6, to run a Linux 5.17* guest
you'll have to run it in HVM mode, and you won't be able to use it as a
dom0.  (Xen 6.1 will still support Linux 4.5 running in PV mode, however.)

 -George

* Making up version numbers here, obviously

[toc] | [prev] | [next] | [standalone]

#1378062 — Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> So more to it, if the EFI entry already provides a way into Linux
> in a more streamlined fashion bringing it closer to the bare metal
> boot entry, why *would* we add another boot entry to x86, even if
> its small and self contained ?

We would avoid using EFI if:

* Being called both on real hardware and under Xen would make the EFI
entry point more complicated

* Adding the necessary EFI support into Xen would be a significant
chunk of extra work

* Requiring PVH mode to implement EFI would make it more difficult for
other kernes (NetBSD, FreeBSD) to act as dom0s.

* Requiring PVH mode to use EFI would make it more difficult to
support unikernel-style workloads for domUs.

Now as has been pointed out, we don't know for a lot of the above
things for certain, because nobody has posted any code.  None of us
really want to post any code because:

* Reading and understanding the EFI spec, the Linux EFI path, and
implementing all that on both the Xen and the Linux side is a lot of
work

* It looks pretty likely that many of the above things will be true

* The only real objection to the currently proposed solution is really weak.

If you want to post some code I'm sure we could give you feedback on it.

> Another position against small stubs which I listed myself is that we may need
> more semantics for early boot even if the new HVMLite small stub is added. This
> remains to be seen. If we are going to add new semantics, it would seem best to
> use something more standard like EFI configuration tables rather than hack on
> to x86 further custom semantics. Custom sloppy semantics have proven to be
> misused, and were ultimately a sloppy mess.
[snip]
>> That sounds like it's going to make the EFI path just as unmanageable as the
>> current PV path.
>
> Can you describe how?
>
>> Using the EFI entry point would certainly make sense if it was
>> actually simpler than the proposed extra entry point.  But it sounds
>> like it's going to be more complicated, not only for Xen, but also for
>> Linux.
>
> How so? Please provide specifics.

Here is the juxtaposition that confuses me.  The problem with a lot of
the current code is that you have virtualization-specific hacks all
over the place making things complicated.  And in the first quote
above, you seem afraid that the extra entry point with stub code will
somehow be misused and end up in a similar "sloppy mess", even though
it's not at all clear how *having a stub entry point* could be
"abused" by anyone.  But then when I suggest that sharing a codepath
between systems that have actual EFI firmware, with platform hardware,
and a system that has no EFI firmware and no similar concept of the
hardware, might end up a sloppy mess of Xen-specific if clauses and
maintenance headaches due to broken assumptions, it doesn't even
register with you as a reasonable concern?

As Matt said, nobody will be able to provide specifics until someone
tries to code it up.  But coding things up is not free.

 -George

[toc] | [prev] | [next] | [standalone]

#1378245 — Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote:
> On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> > So more to it, if the EFI entry already provides a way into Linux
> > in a more streamlined fashion bringing it closer to the bare metal
> > boot entry, why *would* we add another boot entry to x86, even if
> > its small and self contained ?
> 
> We would avoid using EFI if:

And this is what I was looking for, thanks!

> * Being called both on real hardware and under Xen would make the EFI
> entry point more complicated

That's on the EFI Linux maintainer to assess. And he seems willing to
consider this.

> * Adding the necessary EFI support into Xen would be a significant
> chunk of extra work

This seems to be a good sticking point, but Andi noted another aspect
of this or redundancy as well.

> * Requiring PVH mode to implement EFI would make it more difficult for
> other kernes (NetBSD, FreeBSD) to act as dom0s.

What if this is an option only then ?

> 
> * Requiring PVH mode to use EFI would make it more difficult to
> support unikernel-style workloads for domUs.

What if this is an option only then ?

> Now as has been pointed out, we don't know for a lot of the above
> things for certain, because nobody has posted any code.  None of us
> really want to post any code because:
> 
> * Reading and understanding the EFI spec, the Linux EFI path, and
> implementing all that on both the Xen and the Linux side is a lot of
> work
> 
> * It looks pretty likely that many of the above things will be true
> 
> * The only real objection to the currently proposed solution is really weak.

Not true:

  * Avoiding code duplication
  * Semantics may be needed anyway


> If you want to post some code I'm sure we could give you feedback on it.

Part of my engagement on HVMLite review is *because* I have been posting
code to help proactively address some old classic PV path issues and
semantics.

I've been addressing semantics on the PV path, and trying to help
bring the classic PV path closer to native entry points while trying
to also provide a proactive measure to help address regressions on the
classic PV path without having Xen be a bottleneck for x86 development.

As for the EFI stuff -- its discussion now as it'd be pointless to
throw out code if we already know we can't go down a path.

> > Another position against small stubs which I listed myself is that we may need
> > more semantics for early boot even if the new HVMLite small stub is added. This
> > remains to be seen. If we are going to add new semantics, it would seem best to
> > use something more standard like EFI configuration tables rather than hack on
> > to x86 further custom semantics. Custom sloppy semantics have proven to be
> > misused, and were ultimately a sloppy mess.
> [snip]
> >> That sounds like it's going to make the EFI path just as unmanageable as the
> >> current PV path.
> >
> > Can you describe how?
> >
> >> Using the EFI entry point would certainly make sense if it was
> >> actually simpler than the proposed extra entry point.  But it sounds
> >> like it's going to be more complicated, not only for Xen, but also for
> >> Linux.
> >
> > How so? Please provide specifics.
> 
> Here is the juxtaposition that confuses me.  The problem with a lot of
> the current code is that you have virtualization-specific hacks all
> over the place making things complicated.

That's because of sloppy solutions.

> And in the first quote
> above, you seem afraid that the extra entry point with stub code will
> somehow be misused and end up in a similar "sloppy mess", even though
> it's not at all clear how *having a stub entry point* could be
> "abused" by anyone.

You seem to be missing the points I've raised to Boris about semantics
and requirements for custom platform stuff.

>  But then when I suggest that sharing a codepath
> between systems that have actual EFI firmware, with platform hardware,
> and a system that has no EFI firmware and no similar concept of the
> hardware, might end up a sloppy mess of Xen-specific if clauses and
> maintenance headaches due to broken assumptions, it doesn't even
> register with you as a reasonable concern?

Quite the contrary! It does, the question is how we are going to address
the semantics clearly. EFI seemed to provide an OS agnostic way to
address some of this through configuration tables, which would mean
not having to extend the old x86 boot protocol further. More to the
point, this is beyond x86, if we are going to be striving to unify
entry points on Linux across architectures in the long term why not
start addressing needed semantics for virtualization through more
standard mean now?

> As Matt said, nobody will be able to provide specifics until someone
> tries to code it up.  But coding things up is not free.

And he is, but privately shared so far. We still can benefit from
more architectural discussion over these things.

  Luis

[toc] | [prev] | [next] | [standalone]

#1378665 — Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On 13/04/16 20:52, Luis R. Rodriguez wrote:
> On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote:
>> On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>>> So more to it, if the EFI entry already provides a way into Linux
>>> in a more streamlined fashion bringing it closer to the bare metal
>>> boot entry, why *would* we add another boot entry to x86, even if
>>> its small and self contained ?
>>
>> We would avoid using EFI if:
> 
> And this is what I was looking for, thanks!
> 
>> * Being called both on real hardware and under Xen would make the EFI
>> entry point more complicated
> 
> That's on the EFI Linux maintainer to assess. And he seems willing to
> consider this.
> 
>> * Adding the necessary EFI support into Xen would be a significant
>> chunk of extra work
> 
> This seems to be a good sticking point, but Andi noted another aspect
> of this or redundancy as well.
> 
>> * Requiring PVH mode to implement EFI would make it more difficult for
>> other kernes (NetBSD, FreeBSD) to act as dom0s.
> 
> What if this is an option only then ?
> 
>>
>> * Requiring PVH mode to use EFI would make it more difficult to
>> support unikernel-style workloads for domUs.
> 
> What if this is an option only then ?

So first of all, you asked why anyone would oppose EFI, and this is part
of the answer to that.

Secondly, you mean "What if this is the only thing the Linux maintainers
will accept?"  And you already know the answer to that.

How much of a burden it would be on the rest of the open-source
ecosystem (Xen, *BSDs, &c) is a combination of some as-yet unknown facts
(i.e., what a minimal Xen/Linux EFI interface would look like) and a
matter of judgement (i.e., given the same interface, reasonable people
may come to different conclusions about whether the interface is an
undue burden to impose on others or not).

But I would hope that the Linux maintainers would at least consider the
broader community when weighing their decisions, and not take advantage
of their position of dominance to simply ignore the effect of their
choices on everybody else.

 -George

[toc] | [prev] | [next] | [standalone]

#1379266 — Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 10:53:47AM +0100, George Dunlap wrote:
> On 13/04/16 20:52, Luis R. Rodriguez wrote:
> > On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote:
> >> On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> >>> So more to it, if the EFI entry already provides a way into Linux
> >>> in a more streamlined fashion bringing it closer to the bare metal
> >>> boot entry, why *would* we add another boot entry to x86, even if
> >>> its small and self contained ?
> >>
> >> We would avoid using EFI if:
> > 
> > And this is what I was looking for, thanks!
> > 
> >> * Being called both on real hardware and under Xen would make the EFI
> >> entry point more complicated
> > 
> > That's on the EFI Linux maintainer to assess. And he seems willing to
> > consider this.
> > 
> >> * Adding the necessary EFI support into Xen would be a significant
> >> chunk of extra work
> > 
> > This seems to be a good sticking point, but Andi noted another aspect
> > of this or redundancy as well.
> > 
> >> * Requiring PVH mode to implement EFI would make it more difficult for
> >> other kernes (NetBSD, FreeBSD) to act as dom0s.
> > 
> > What if this is an option only then ?
> > 
> >>
> >> * Requiring PVH mode to use EFI would make it more difficult to
> >> support unikernel-style workloads for domUs.
> > 
> > What if this is an option only then ?
> 
> So first of all, you asked why anyone would oppose EFI, and this is part
> of the answer to that.
> 
> Secondly, you mean "What if this is the only thing the Linux maintainers
> will accept?"  And you already know the answer to that.

No, I meant to ask, would it be possible to make booting HVMLite using EFI
be optional ? That way if you already support EFI that can be used on
your entires with some small modifications.

> How much of a burden it would be on the rest of the open-source
> ecosystem (Xen, *BSDs, &c) is a combination of some as-yet unknown facts
> (i.e., what a minimal Xen/Linux EFI interface would look like) and a
> matter of judgement (i.e., given the same interface, reasonable people
> may come to different conclusions about whether the interface is an
> undue burden to impose on others or not).
> 
> But I would hope that the Linux maintainers would at least consider the
> broader community when weighing their decisions, and not take advantage
> of their position of dominance to simply ignore the effect of their
> choices on everybody else.

This has nothing to do with dominance or anything nefarious, I'm asking
simply for a full engineering evaluation of all possibilities, with
the long term in mind. Not for now, but for hardware assumptions which
are sensible 5 years from now.

  Luis

[toc] | [prev] | [next] | [standalone]

#1379297 — Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

> This has nothing to do with dominance or anything nefarious, I'm asking
> simply for a full engineering evaluation of all possibilities, with
> the long term in mind. Not for now, but for hardware assumptions which
> are sensible 5 years from now.

There are two different things in my mind about this conversation:

 1). semantics of low-level code wrapped around pvops. On baremetal
   it is easy - just look at Intel and AMD SDM.
   And this is exactly what running in HVM or HVMLite mode will do -
   all those low-level operations will have the same exact semantic
   as baremetal.

   There is no hope for the pv_ops to fix that.

   And I am pretty sure the HVMLite in 5 years will have no
   trouble in this as it will be running in VMX mode (HVM).
   
 2). Boot entry.

   The semantics on Linux are well known - they are documented in
   Documentation/x86/boot.txt.

   HVMLite Linux guests have to somehow provide that.

   And how it is done seems to be tied around:

   a) Use existing boot paths - which means making some
      extra stub code to call in those existing boot paths
      (for example Xen could bundle with an GRUB2-alike
       code to be run when booting Linux using that boot-path).

      Or EFI (for a ton more code). Granted not all OSes
      support those, so not very OS agnostic.

       Hard part - if the bootparams change then have to
      rev up the code in there. May be out of sync
      with Linux bootparams.

   b) Add another simpler boot entry point which has to copy
     "some" strings from its format in bootparams.


   So this part of the discussion does not fall in the
   hardware assumptions. Intel SDM or AMD mention nothing about
   boot loaders or how to boot an OS - that is all in realms
   of how software talks to software.

 3). And there is the discussion on man-power to make this
   happen.

 4). Lastly which one is simpler and involves less code so
    that there is a less chance of bitrot.

[toc] | [prev] | [next] | [standalone]

#1379308 — Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 04:38:47PM -0400, Konrad Rzeszutek Wilk wrote:
> > This has nothing to do with dominance or anything nefarious, I'm asking
> > simply for a full engineering evaluation of all possibilities, with
> > the long term in mind. Not for now, but for hardware assumptions which
> > are sensible 5 years from now.
> 
> There are two different things in my mind about this conversation:
> 
>  1). semantics of low-level code wrapped around pvops. On baremetal
>    it is easy - just look at Intel and AMD SDM.
>    And this is exactly what running in HVM or HVMLite mode will do -
>    all those low-level operations will have the same exact semantic
>    as baremetal.

Today Linux is KVM stupid for early boot code. I've pointed this out
before, but again, there has been no reason found to need this. Perhaps
for HVMLite we won't need this...

>    There is no hope for the pv_ops to fix that.

Actually I beg to differ. See my patches and ongoing work.

>    And I am pretty sure the HVMLite in 5 years will have no
>    trouble in this as it will be running in VMX mode (HVM).

HVMLite may still use PV drivers for some things, its not super
obvious to me that low level semantics will not be needed yet.

>  2). Boot entry.
> 
>    The semantics on Linux are well known - they are documented in
>    Documentation/x86/boot.txt.
> 
>    HVMLite Linux guests have to somehow provide that.
> 
>    And how it is done seems to be tied around:
> 
>    a) Use existing boot paths - which means making some
>       extra stub code to call in those existing boot paths
>       (for example Xen could bundle with an GRUB2-alike
>        code to be run when booting Linux using that boot-path).
> 
>       Or EFI (for a ton more code). Granted not all OSes
>       support those, so not very OS agnostic.

What other OSes do is something to consider but if they don't
do it because they are slacking in one domain should by no means
be a reason to not evaluate the long term possible gains.
Specially if we have reasons to believe more architectures will
consider it and standardize on it.

It'd be silly not to take this a bit more seriously.

>        Hard part - if the bootparams change then have to
>       rev up the code in there. May be out of sync
>       with Linux bootparams.

If we are going to ultimately standardize on EFI boot for new
hardware it'd be rather silly to extend the boot params further.

>    b) Add another simpler boot entry point which has to copy
>      "some" strings from its format in bootparams.
> 
> 
>    So this part of the discussion does not fall in the
>    hardware assumptions. Intel SDM or AMD mention nothing about
>    boot loaders or how to boot an OS - that is all in realms
>    of how software talks to software.

Right -- so one question to ask here is what other uses are there
for this outside of say HVMLite. You mentioned Multiboot so far.

>  3). And there is the discussion on man-power to make this
>    happen.

Sure.

>  4). Lastly which one is simpler and involves less code so
>     that there is a less chance of bitrot.

Indeed.

You also forgot the tie-in between dead-code and semantics but
that clearly is not on your mind. But I'd say this is a good
summary.

  Luis

[toc] | [prev] | [next] | [standalone]

#1379421 — Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 11:12:01PM +0200, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 04:38:47PM -0400, Konrad Rzeszutek Wilk wrote:
> > > This has nothing to do with dominance or anything nefarious, I'm asking
> > > simply for a full engineering evaluation of all possibilities, with
> > > the long term in mind. Not for now, but for hardware assumptions which
> > > are sensible 5 years from now.
> > 
> > There are two different things in my mind about this conversation:
> > 
> >  1). semantics of low-level code wrapped around pvops. On baremetal
> >    it is easy - just look at Intel and AMD SDM.
> >    And this is exactly what running in HVM or HVMLite mode will do -
> >    all those low-level operations will have the same exact semantic
> >    as baremetal.
> 
> Today Linux is KVM stupid for early boot code. I've pointed this out

-EPARSE?
> before, but again, there has been no reason found to need this. Perhaps
> for HVMLite we won't need this...

Are you talking about kvmtools? Which BTW are similar to how HVMLite
would expose the platform.
> 
> >    There is no hope for the pv_ops to fix that.
> 
> Actually I beg to differ. See my patches and ongoing work.

I meant in terms of semantics. As in I cannot see some of
those pv-ops to have the same semantics as baremetal. For example
set_pte is simple on x86 (movq $<some value>, <memory address>).

While on Xen PV it is a potential batching hypercall with
lookup in an P2M table, then perhaps a sidelong look at
the M2P, then maybe the M2P override.

> 
> >    And I am pretty sure the HVMLite in 5 years will have no
> >    trouble in this as it will be running in VMX mode (HVM).
> 
> HVMLite may still use PV drivers for some things, its not super
> obvious to me that low level semantics will not be needed yet.

PV drivers are very different from low-level semantics.

And it will have to use them.

Maybe it is easier to think of this in terms of kvmtool - it
is pretty much how this would work - but instead of VirtIO
drivers you would be using the Xen PV drivers (thought one
could also use VirtIO ones if you wanted).
> 
> >  2). Boot entry.
> > 
> >    The semantics on Linux are well known - they are documented in
> >    Documentation/x86/boot.txt.
> > 
> >    HVMLite Linux guests have to somehow provide that.
> > 
> >    And how it is done seems to be tied around:
> > 
> >    a) Use existing boot paths - which means making some
> >       extra stub code to call in those existing boot paths
> >       (for example Xen could bundle with an GRUB2-alike
> >        code to be run when booting Linux using that boot-path).
> > 
> >       Or EFI (for a ton more code). Granted not all OSes
> >       support those, so not very OS agnostic.
> 
> What other OSes do is something to consider but if they don't
> do it because they are slacking in one domain should by no means
> be a reason to not evaluate the long term possible gains.
> Specially if we have reasons to believe more architectures will
> consider it and standardize on it.
> 
> It'd be silly not to take this a bit more seriously.

Complexity vs simplicity.
> 
> >        Hard part - if the bootparams change then have to
> >       rev up the code in there. May be out of sync
> >       with Linux bootparams.
> 
> If we are going to ultimately standardize on EFI boot for new
> hardware it'd be rather silly to extend the boot params further.

Whoa there... Have you spoken to hpa,tglrx about this?

> 
> >    b) Add another simpler boot entry point which has to copy
> >      "some" strings from its format in bootparams.
> > 
> > 
> >    So this part of the discussion does not fall in the
> >    hardware assumptions. Intel SDM or AMD mention nothing about
> >    boot loaders or how to boot an OS - that is all in realms
> >    of how software talks to software.
> 
> Right -- so one question to ask here is what other uses are there
> for this outside of say HVMLite. You mentioned Multiboot so far.
> 
> >  3). And there is the discussion on man-power to make this
> >    happen.
> 
> Sure.
> 
> >  4). Lastly which one is simpler and involves less code so
> >     that there is a less chance of bitrot.
> 
> Indeed.
> 
> You also forgot the tie-in between dead-code and semantics but

Wait, I just spoke about CPU semantics?! Which semantics
are you talking about?
> that clearly is not on your mind. But I'd say this is a good
> summary.

I put 'dead code' in the same realm as device drivers work.
And they seem to always have some issue or another.
Or maybe I getting unlucky and getting copied on those bugs.
> 
>   Luis

[toc] | [prev] | [next] | [standalone]

#1379465 — Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On 14/04/16 21:44, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 10:53:47AM +0100, George Dunlap wrote:
>> On 13/04/16 20:52, Luis R. Rodriguez wrote:
>>> On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote:
>>>> On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>>>>> So more to it, if the EFI entry already provides a way into Linux
>>>>> in a more streamlined fashion bringing it closer to the bare metal
>>>>> boot entry, why *would* we add another boot entry to x86, even if
>>>>> its small and self contained ?
>>>>
>>>> We would avoid using EFI if:
>>>
>>> And this is what I was looking for, thanks!
>>>
>>>> * Being called both on real hardware and under Xen would make the EFI
>>>> entry point more complicated
>>>
>>> That's on the EFI Linux maintainer to assess. And he seems willing to
>>> consider this.
>>>
>>>> * Adding the necessary EFI support into Xen would be a significant
>>>> chunk of extra work
>>>
>>> This seems to be a good sticking point, but Andi noted another aspect
>>> of this or redundancy as well.
>>>
>>>> * Requiring PVH mode to implement EFI would make it more difficult for
>>>> other kernes (NetBSD, FreeBSD) to act as dom0s.
>>>
>>> What if this is an option only then ?
>>>
>>>>
>>>> * Requiring PVH mode to use EFI would make it more difficult to
>>>> support unikernel-style workloads for domUs.
>>>
>>> What if this is an option only then ?
>>
>> So first of all, you asked why anyone would oppose EFI, and this is part
>> of the answer to that.
>>
>> Secondly, you mean "What if this is the only thing the Linux maintainers
>> will accept?"  And you already know the answer to that.
> 
> No, I meant to ask, would it be possible to make booting HVMLite using EFI
> be optional ? That way if you already support EFI that can be used on
> your entires with some small modifications.

So you suggest to add two HVMlite modes regarding boot interface
instead of one?

I still have the impression you are suggesting by using the same entry
everything is solved in the OS. You still need the support of HVMlite
especially in the early boot path to make sure the OS won't try to use
the complete EFI standard.

> 
>> How much of a burden it would be on the rest of the open-source
>> ecosystem (Xen, *BSDs, &c) is a combination of some as-yet unknown facts
>> (i.e., what a minimal Xen/Linux EFI interface would look like) and a
>> matter of judgement (i.e., given the same interface, reasonable people
>> may come to different conclusions about whether the interface is an
>> undue burden to impose on others or not).
>>
>> But I would hope that the Linux maintainers would at least consider the
>> broader community when weighing their decisions, and not take advantage
>> of their position of dominance to simply ignore the effect of their
>> choices on everybody else.
> 
> This has nothing to do with dominance or anything nefarious, I'm asking
> simply for a full engineering evaluation of all possibilities, with
> the long term in mind. Not for now, but for hardware assumptions which
> are sensible 5 years from now.

No, they are not.

Given how long the EFI standard is available now and how buggy many
vendor's implementations are I don't expect all computers sold in 5
years will have a usable EFI. This will be true especially for
consumer devices where no EFI is available today.


Juergen

[toc] | [prev] | [next] | [standalone]

#1379921 — Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Fri, Apr 15, 2016 at 07:50:25AM +0200, Juergen Gross wrote:
> On 14/04/16 21:44, Luis R. Rodriguez wrote:
> > No, I meant to ask, would it be possible to make booting HVMLite using EFI
> > be optional ? That way if you already support EFI that can be used on
> > your entires with some small modifications.
> 
> So you suggest to add two HVMlite modes regarding boot interface
> instead of one?

Not suggest, I'm evaluating what options we have available. That's very
different from suggesting. That's the point to this whole topic, pure and
simple evaluation of options.

> Given how long the EFI standard is available now and how buggy many
> vendor's implementations are I don't expect all computers sold in 5
> years will have a usable EFI. This will be true especially for
> consumer devices where no EFI is available today.

Thanks this really helps.

  Luis

[toc] | [prev] | [next] | [standalone]

#1379652 — Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On 14/04/16 20:44, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 10:53:47AM +0100, George Dunlap wrote:
>> On 13/04/16 20:52, Luis R. Rodriguez wrote:
>>> On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote:
>>>> On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>>>>> So more to it, if the EFI entry already provides a way into Linux
>>>>> in a more streamlined fashion bringing it closer to the bare metal
>>>>> boot entry, why *would* we add another boot entry to x86, even if
>>>>> its small and self contained ?
>>>>
>>>> We would avoid using EFI if:
>>>
>>> And this is what I was looking for, thanks!
>>>
>>>> * Being called both on real hardware and under Xen would make the EFI
>>>> entry point more complicated
>>>
>>> That's on the EFI Linux maintainer to assess. And he seems willing to
>>> consider this.
>>>
>>>> * Adding the necessary EFI support into Xen would be a significant
>>>> chunk of extra work
>>>
>>> This seems to be a good sticking point, but Andi noted another aspect
>>> of this or redundancy as well.
>>>
>>>> * Requiring PVH mode to implement EFI would make it more difficult for
>>>> other kernes (NetBSD, FreeBSD) to act as dom0s.
>>>
>>> What if this is an option only then ?
>>>
>>>>
>>>> * Requiring PVH mode to use EFI would make it more difficult to
>>>> support unikernel-style workloads for domUs.
>>>
>>> What if this is an option only then ?
>>
>> So first of all, you asked why anyone would oppose EFI, and this is part
>> of the answer to that.
>>
>> Secondly, you mean "What if this is the only thing the Linux maintainers
>> will accept?"  And you already know the answer to that.
> 
> No, I meant to ask, would it be possible to make booting HVMLite using EFI
> be optional ? That way if you already support EFI that can be used on
> your entires with some small modifications.

Oh -- I read both those lines as, "What if this is *the only option*
then?" (which I then interpreted to mean, what if booting EFI is the
only thing Linux will accept).  The rest of my reply is based on that
misunderstanding.  Sorry about that.

Regarding the second one -- I wasn't talking about actual non-Linux
unikernels; I was talking about using Linux in the way that unikernels
are used ("unikernel-style").  That is, you boot a minimal Linux image
with a small ramdisk and have a single process running as init.  For
this use case, even an extra megabyte of guest RAM and an extra second
of boot time is a significant cost.  "Use OVMF for domUs" is an
excellent solution for traditional VMs where you boot a full distro, but
would impose a significant cost on using Linux in unikernel-style VMs.

Whether a stripped-down EFI support would be sufficiently low memory /
latency for such workloads is an open question that would take time and
engineering effort to discover.  And in any case, it would certainly
require the maintenance of Yet Another Bootloader in the Xen source tree.

 -George

[toc] | [prev] | [next] | [standalone]

#1379926 — Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Fri, Apr 15, 2016 at 10:59:16AM +0100, George Dunlap wrote:
> On 14/04/16 20:44, Luis R. Rodriguez wrote:
> > No, I meant to ask, would it be possible to make booting HVMLite using EFI
> > be optional ? That way if you already support EFI that can be used on
> > your entires with some small modifications.
> 
> I wasn't talking about actual non-Linux unikernels; I was talking about using
> Linux in the way that unikernels are used ("unikernel-style").  That is, you
> boot a minimal Linux image with a small ramdisk and have a single process
> running as init.  For this use case, even an extra megabyte of guest RAM and
> an extra second of boot time is a significant cost.  "Use OVMF for domUs" is
> an excellent solution for traditional VMs where you boot a full distro, but
> would impose a significant cost on using Linux in unikernel-style VMs.

Understood.

> Whether a stripped-down EFI support would be sufficiently low memory /
> latency for such workloads is an open question that would take time and
> engineering effort to discover.  And in any case, it would certainly
> require the maintenance of Yet Another Bootloader in the Xen source tree.

OVMF is used by ARM, so using it should be a matter of adaptation, and
some changes other than perhaps DT use. Question still stands though,
would it be possible to have HVMLite be using EFI as an option so that
some users could opt-in if they so wish ?

To be clear, at this point I am not suggesting this be done, just evaluating
the options available.

  Luis

[toc] | [prev] | [next] | [standalone]

#1379960 — Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On 15/04/16 16:30, Luis R. Rodriguez wrote:
> On Fri, Apr 15, 2016 at 10:59:16AM +0100, George Dunlap wrote:
>> On 14/04/16 20:44, Luis R. Rodriguez wrote:
>>> No, I meant to ask, would it be possible to make booting HVMLite using EFI
>>> be optional ? That way if you already support EFI that can be used on
>>> your entires with some small modifications.
>>
>> I wasn't talking about actual non-Linux unikernels; I was talking about using
>> Linux in the way that unikernels are used ("unikernel-style").  That is, you
>> boot a minimal Linux image with a small ramdisk and have a single process
>> running as init.  For this use case, even an extra megabyte of guest RAM and
>> an extra second of boot time is a significant cost.  "Use OVMF for domUs" is
>> an excellent solution for traditional VMs where you boot a full distro, but
>> would impose a significant cost on using Linux in unikernel-style VMs.
> 
> Understood.
> 
>> Whether a stripped-down EFI support would be sufficiently low memory /
>> latency for such workloads is an open question that would take time and
>> engineering effort to discover.  And in any case, it would certainly
>> require the maintenance of Yet Another Bootloader in the Xen source tree.
> 
> OVMF is used by ARM, so using it should be a matter of adaptation, and
> some changes other than perhaps DT use. Question still stands though,
> would it be possible to have HVMLite be using EFI as an option so that
> some users could opt-in if they so wish ?

Well we definitely intend go have a mode of PVH* which boots OVMF to
EFI-enabled guests, if that's what you mean.  For one thing, that should
in theory allow us to boot Windows guests without needing to spin up
qemu to emulate any devices (since OVMF will be able to access the PV
devices until the Windows PV drivers come up).  Booting to EFI-enabled
distros is certainly something we want as well.

But we need an option for dom0, and ideally we'd like an option for
lightweight Linux guests.  It's using EFI for those purposes that we're
pushing back on.

 -George

* I'm saying PVH because I hope when everything is sorted out we can
just call HVMLite PVH again.

[toc] | [prev] | [next] | [standalone]

#1372406

On Wed, Apr 06, 2016 at 04:40:27AM +0200, Luis R. Rodriguez wrote:
> Boris sent out the first HVMLite series of patches to add a new Xen guest type
> February 1, 2016 [0]. We've been talking off list with a few folks now over
> the prospect of instead of adding yet-another-boot-entry we instead fixate
> HVMLite to use the x86 EFI boot entry. There's a series of reasons to consider
> this, likewise there are reasons to question the effort required and if its
> really needed. We'd like some more public review of this proposal, and see if
> others can come up with other ideas, both in favor or against this proposal.
>
> This in particular is also a good time to get x86 Linux folks to chime on on
> the general design proposal of HVMLite design, given that outside of the boot
> entry discussion it would seem including myself that we didn't get the memo
> over the proposed architecture review [1]. At least on my behalf perhaps the
> only sticking thorns of the design was the new boot entry, which came to me
> as a surprise, and this thread addresses and the lack of addressing semantics
> for early boot (which we may seem to need to address; some of this is being
> addressing in parallels through other work). The HVMLite document talks about
> using ACPI_FADT_NO_VGA -- we don't use this yet upstream but I have some pending
> changes which should make it easy to integrate its use on HVMLite. Perhaps
> there are others that may have some other points they may want to raise now...
>
> A huge summary of the discussion over EFI boot option for HVMLite is now on a
> wiki [2], below I'll just provide the outline of the discussion. Consider this a
> request for more public review, feel free to take any of the items below and
> elaborate on it as you see fit.
>
> Worth mentioning also is that this topic will be discussed at the 2016 Xen
> Hackathon April 18-19 [3] at the ARM Cambridge, UK Headquarters so if you can
> attend and this topic interests you, consider attending.

I hope that you will be there as one of the biggest proponents of EFI entry point.
If you does not it will be difficult or impossible to discuss this issue without you.
In the worst case I can raise this topic on behalf of you and then we should organize
phone call if possible (and accepted by others). However, to do that I must know your
plans in advance.

Daniel

[toc] | [prev] | [next] | [standalone]

#1373689

On Wed, Apr 06, 2016 at 01:11:30PM +0200, Daniel Kiper wrote:
> On Wed, Apr 06, 2016 at 04:40:27AM +0200, Luis R. Rodriguez wrote:
> > Boris sent out the first HVMLite series of patches to add a new Xen guest type
> > February 1, 2016 [0]. We've been talking off list with a few folks now over
> > the prospect of instead of adding yet-another-boot-entry we instead fixate
> > HVMLite to use the x86 EFI boot entry. There's a series of reasons to consider
> > this, likewise there are reasons to question the effort required and if its
> > really needed. We'd like some more public review of this proposal, and see if
> > others can come up with other ideas, both in favor or against this proposal.
> >
> > This in particular is also a good time to get x86 Linux folks to chime on on
> > the general design proposal of HVMLite design, given that outside of the boot
> > entry discussion it would seem including myself that we didn't get the memo
> > over the proposed architecture review [1]. At least on my behalf perhaps the
> > only sticking thorns of the design was the new boot entry, which came to me
> > as a surprise, and this thread addresses and the lack of addressing semantics
> > for early boot (which we may seem to need to address; some of this is being
> > addressing in parallels through other work). The HVMLite document talks about
> > using ACPI_FADT_NO_VGA -- we don't use this yet upstream but I have some pending
> > changes which should make it easy to integrate its use on HVMLite. Perhaps
> > there are others that may have some other points they may want to raise now...
> >
> > A huge summary of the discussion over EFI boot option for HVMLite is now on a
> > wiki [2], below I'll just provide the outline of the discussion. Consider this a
> > request for more public review, feel free to take any of the items below and
> > elaborate on it as you see fit.
> >
> > Worth mentioning also is that this topic will be discussed at the 2016 Xen
> > Hackathon April 18-19 [3] at the ARM Cambridge, UK Headquarters so if you can
> > attend and this topic interests you, consider attending.
> 
> I hope that you will be there as one of the biggest proponents of EFI entry point.

It would be a last minute trip to prepare for...

> If you does not it will be difficult or impossible to discuss this issue without you.
> In the worst case I can raise this topic on behalf of you and then we should organize
> phone call if possible (and accepted by others). However, to do that I must know your
> plans in advance.

I understand, I'd like to make it clear I am taking simply a neutral position
on this topic, even though it may seem I'm a die-hard on this idea, this was
simply an architectural question that came up, and I have been just
dissatisfied with the answers against the architectural questions I had over
this.

To help better evaluate how neutral really a discussion like this can be
can someone please help chime in on the question of if there are pressures to
just complete HVMLite design already ? How strong are those ? Are we really
able to have a very neutral technical discussion on this ?

  Luis

[toc] | [prev] | [next] | [standalone]

#1374655

On Wed, Apr 06, 2016 at 01:11:30PM +0200, Daniel Kiper wrote:
> On Wed, Apr 06, 2016 at 04:40:27AM +0200, Luis R. Rodriguez wrote:
> > Boris sent out the first HVMLite series of patches to add a new Xen guest type
> > February 1, 2016 [0]. We've been talking off list with a few folks now over
> > the prospect of instead of adding yet-another-boot-entry we instead fixate
> > HVMLite to use the x86 EFI boot entry. There's a series of reasons to consider
> > this, likewise there are reasons to question the effort required and if its
> > really needed. We'd like some more public review of this proposal, and see if
> > others can come up with other ideas, both in favor or against this proposal.
> >
> > This in particular is also a good time to get x86 Linux folks to chime on on
> > the general design proposal of HVMLite design, given that outside of the boot
> > entry discussion it would seem including myself that we didn't get the memo
> > over the proposed architecture review [1]. At least on my behalf perhaps the
> > only sticking thorns of the design was the new boot entry, which came to me
> > as a surprise, and this thread addresses and the lack of addressing semantics
> > for early boot (which we may seem to need to address; some of this is being
> > addressing in parallels through other work). The HVMLite document talks about
> > using ACPI_FADT_NO_VGA -- we don't use this yet upstream but I have some pending
> > changes which should make it easy to integrate its use on HVMLite. Perhaps
> > there are others that may have some other points they may want to raise now...
> >
> > A huge summary of the discussion over EFI boot option for HVMLite is now on a
> > wiki [2], below I'll just provide the outline of the discussion. Consider this a
> > request for more public review, feel free to take any of the items below and
> > elaborate on it as you see fit.
> >
> > Worth mentioning also is that this topic will be discussed at the 2016 Xen
> > Hackathon April 18-19 [3] at the ARM Cambridge, UK Headquarters so if you can
> > attend and this topic interests you, consider attending.
> 
> I hope that you will be there as one of the biggest proponents of EFI entry point.
> If you does not it will be difficult or impossible to discuss this issue without you.
> In the worst case I can raise this topic on behalf of you and then we should organize
> phone call if possible (and accepted by others). However, to do that I must know your
> plans in advance.

I'll be there!

  Luis

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web