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 Matt Fleming <matt@codeblueprint.co.uk> - 2016-04-16 01: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 "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-15 19: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 Stefano Stabellini <sstabellini@kernel.org> - 2016-04-15 20:50 +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: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-04-15 19:20 +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 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

Hello Luis,

On 14/04/16 21:56, Luis R. Rodriguez wrote:
> On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Thu, Apr 14, 2016 at 08:40:48PM +0200, Luis R. Rodriguez wrote:
>>> On Wed, Apr 13, 2016 at 09:01:32PM -0400, Konrad Rzeszutek Wilk wrote:
>>>> On Thu, Apr 14, 2016 at 12:23:17AM +0200, Luis R. Rodriguez wrote:
>>> PV support from the kernel (not the hypervisor) and require hardware
>>> virtualization 5 years from now on the Linux kernel, it doesn't seem
>>> to me far fetched to at the very least consider using an EFI entry
>>> instead, specially since all it does is set boot params and we can
>>> make re-use this for HVMLite too.
>>
>> But to make that work you have to emulate EFI firmware in the
>> hypervisor. Is that work you are signing up for?
>
> I'll do what is needed, as I have done before. If EFI is on the long
> term roadmap for ARM perhaps there are a few birds to knock with one
> stone here. If there is also interest to support other OSes through
> EFI standard means this also should help make that easier.

We already have a working solution for EFI on ARM which does not require 
to emulate the firmware in the hypervisor.

On ARM, the EFI stub is communicating with the kernel using device-tree 
[1]. Once the EFI stub has ended, the native path (i.e non-UEFI) will be 
executed normally and it won't be possible to use BootServices anymore.

For the guest, we provide a full support of EFI using OVMF. For DOM0, 
Xen will craft the UEFI system table and the UEFI memory map. The 
locations of those tables will be passed to DOM0 using a tiny 
device-tree [1] and the kernel will boot using the native path. The 
runtime services for DOM0 will be provided via hypercall.

The DOM0 approach has been discussed for a long time (see [3]) and I 
believe this is better than emulating UEFI firmware in Xen. We want to 
keep Xen on ARM tiny. Adding any sort of emulation will increase the 
attack surface and require more maintenance from our side.

Regards,

[1] Documentation/arm/uefi.txt in Linux.

[2] 
http://xenbits.xen.org/docs/unstable-staging/misc/arm/device-tree/guest.txt

[3] http://www.gossamer-threads.com/lists/xen/devel/397349

-- 
Julien Grall

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

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

On Fri, Apr 15, 2016 at 3:06 AM, Julien Grall <julien.grall@arm.com> wrote:
> On 14/04/16 21:56, Luis R. Rodriguez wrote:
>> On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote:
>>> But to make that work you have to emulate EFI firmware in the
>>> hypervisor. Is that work you are signing up for?
>>
>> I'll do what is needed, as I have done before. If EFI is on the long
>> term roadmap for ARM perhaps there are a few birds to knock with one
>> stone here. If there is also interest to support other OSes through
>> EFI standard means this also should help make that easier.
>
> We already have a working solution for EFI on ARM which does not require to
> emulate the firmware in the hypervisor.

I get that.

> On ARM, the EFI stub is communicating with the kernel using device-tree [1].
> Once the EFI stub has ended, the native path (i.e non-UEFI) will be executed
> normally and it won't be possible to use BootServices anymore.
>
> For the guest, we provide a full support of EFI using OVMF.

I get that as well, is this the long term solution ? That still
requires OVMF, will relying on OVMF always be what is used on Xen ARM
? Was it too much of a burden to require OVMF? Is the upstream OVMF
code pulled by Xen at build time on ARM, or just wget a binary ?

> For DOM0, Xen
> will craft the UEFI system table and the UEFI memory map. The locations of
> those tables will be passed to DOM0 using a tiny device-tree [1] and the
> kernel will boot using the native path. The runtime services for DOM0 will
> be provided via hypercall.

Thanks this helps!

> The DOM0 approach has been discussed for a long time (see [3]) and I believe
> this is better than emulating UEFI firmware in Xen. We want to keep Xen on
> ARM tiny. Adding any sort of emulation will increase the attack surface and
> require more maintenance from our side.

OK thanks, would re-using OVMF (note, DT perhaps may not be ideal for
x86 for the rest though) be a reasonable solution on x86 as an option
then?

  Luis

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

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

On Fri, 15 Apr 2016, Luis R. Rodriguez wrote:
> On Fri, Apr 15, 2016 at 3:06 AM, Julien Grall <julien.grall@arm.com> wrote:
> > On 14/04/16 21:56, Luis R. Rodriguez wrote:
> >> On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote:
> >>> But to make that work you have to emulate EFI firmware in the
> >>> hypervisor. Is that work you are signing up for?
> >>
> >> I'll do what is needed, as I have done before. If EFI is on the long
> >> term roadmap for ARM perhaps there are a few birds to knock with one
> >> stone here. If there is also interest to support other OSes through
> >> EFI standard means this also should help make that easier.
> >
> > We already have a working solution for EFI on ARM which does not require to
> > emulate the firmware in the hypervisor.
> 
> I get that.
> 
> > On ARM, the EFI stub is communicating with the kernel using device-tree [1].
> > Once the EFI stub has ended, the native path (i.e non-UEFI) will be executed
> > normally and it won't be possible to use BootServices anymore.
> >
> > For the guest, we provide a full support of EFI using OVMF.
> 
> I get that as well, is this the long term solution ?

Yes, it is for Xen on ARM.


> That still requires OVMF, will relying on OVMF always be what is used
> on Xen ARM ?

Not always, the native boot path is still supported. It is possible to
boot a VM using "kernel=/path/to/linux" in your VM config file and that
is not going to boot via EFI but via the native boot path.

To summarize, on ARM:

# DomUs options:
1) xl create "kernel=/path/to/ovfm.bin" -> OVMF -> EFI stub -> Linux (regular entry point)
2) xl create "kernel=/path/to/Linux" -> Linux (regular entry point)

# Dom0 options:
1) native UEFI firmare -> Xen (ExitBootServices) -> Linux (regular entry point)
2) uBoot -> Xen -> Linux (regular entry point)


> Was it too much of a burden to require OVMF?

No, it wasn't. Especially because Anthony had already introduced Xen
support in it.


> Is the upstream OVMF code pulled by Xen at build time on ARM, or just
> wget a binary ?

At the moment the build is not integrated, so you need to go and build
it yourself or use Raisin to do it.


> > For DOM0, Xen will craft the UEFI system table and the UEFI memory
> > map. The locations of those tables will be passed to DOM0 using a
> > tiny device-tree [1] and the kernel will boot using the native path.
> > The runtime services for DOM0 will be provided via hypercall.
> 
> Thanks this helps!
> 
> > The DOM0 approach has been discussed for a long time (see [3]) and I believe
> > this is better than emulating UEFI firmware in Xen. We want to keep Xen on
> > ARM tiny. Adding any sort of emulation will increase the attack surface and
> > require more maintenance from our side.
> 
> OK thanks, would re-using OVMF (note, DT perhaps may not be ideal for
> x86 for the rest though) be a reasonable solution on x86 as an option
> then?

Reusing OVMF for HVMLite DomUs should be easy and something to look at
in the future. Reusing OVMF for HVMLite Dom0 is another story. I think
is a bad idea.

If we wanted to do something like we did on ARM, we need to understand
how the Linux internal API on x86 between the EFI stub and the regular
entry point look like. Is there even one? Could we elevate that to an
external interface and use it to boot Linux from Xen? If so, that would
be an option.

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

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

On Wed, Apr 6, 2016 at 3:40 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> 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.
[snip]
>   * Issues with boot x86 boot entries
>     * Small x86 zero page stubs
[snip]
>   * Points against using EFI
>     * Nulling the claimed boot loader effect

I'm a bit confused about this. You list exactly two arguments against
the proposed stub in the "con" section:
1. Bootloaders may not be able to use the extra entry point
2. It's an extra entry point

And then later, in another section, you actually list the reason #1 is
irrelevant: bootloaders don't matter because the stub is there to boot
from the Xen hypervisor.

So the only actual argument you have against the proposed PVH stub in
the linked document is that it's an extra entry point.

>   * Why use EFI for HVMlite
>     * EFI calling conventions are standardized
>     * EFI entry generalizes what new HVMLite entry proposes
>     * Further semantics may be needed
>     * Match Xen ARM's clean solution
>     * You don't need full EFI emulation
>       * Minimal EFI stubs for guests
>         * GetMemoryMap()
>         * ExitBootServices()
>       * EFI stubs which may be needed for guests
>         * Exit()
>         * Variable operation functions
>       * EFI stubs not needed for guests
>         * GetTime()/SetTime()
>         * SetVirtualAddressMap()
>         * ResetSystem()
>       * dom0 EFI
>       * domU EFI emulation possibilities
>         * Xen implements its own EFI environment for guests
>         * Xen uses Tianocore / OVMF

So rather than make a new entry point which does just the minimal
amount of work to run on a software interface (Xen), you want to take
an interface designed for hardware (EFI) and put in hacks so that it
knows that sometimes some EFI services are not available?  That sounds
like it's going to make the EFI path just as unmanageable as the
current PV path.

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.

 -George

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

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

On Wed, 06 Apr, at 12:07:36PM, George Dunlap wrote:
> 
> So rather than make a new entry point which does just the minimal
> amount of work to run on a software interface (Xen), you want to take
> an interface designed for hardware (EFI) and put in hacks so that it
> knows that sometimes some EFI services are not available?  That sounds
> like it's going to make the EFI path just as unmanageable as the
> current PV path.
 
Requiring code in the new entry point to manipulate control registers
and do the switch to long-mode does not seem like a minimal amount of
code to me,

  http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00134.html

What's likely to happen in the future is that startup_(32|64) will be
entered with different settings depending on whether coming from
HVMlite or bare metal, due to the natural tendency for these kinds of
code paths to diverge.

Sometimes EFI runtime services are not available on bare metal
hardware too, for example, when booting 32-bit kernels on 64-bit EFI
or 64-bit kernels on 32-bit EFI without CONFIG_EFI_MIXED. Or when
booting with the "noefi" kernel command line parameter. That's how
things work today when booting Xen, we disable the runtime services.

EFI boot services are a different story however, and the EFI boot stub
would need to be changed to handle that. Though honestly, it would
make more sense to provide EFI services stubs in the kernel image
itself that are implemented using hypercalls, and assuming you can run
hypercalls that early in boot.

One place that struck me as suitable for this "hypercall in an EFI
service stub" approach is the trouble with doing ACPI reboot as
documented here,

  http://lists.xen.org/archives/html/xen-devel/2016-02/msg01609.html

Performing the reset hypercall from within HVMlite's custom EfiReset()
service would avoid having to touch ACPICA at all, and would be
indistinguishable from bare metal.

> 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.

Until someone sits down and writes the code I think we're going to be
arguing back and forth over this particular point.

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

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

On Wed, Apr 06, 2016 at 12:23:47PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Apr 06, 2016 at 12:05:16PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Apr 06, 2016 at 04:02:40PM +0100, Matt Fleming wrote:
> > > On Wed, 06 Apr, at 12:07:36PM, George Dunlap wrote:
> > > > 
> > > > So rather than make a new entry point which does just the minimal
> > > > amount of work to run on a software interface (Xen), you want to take
> > > > an interface designed for hardware (EFI) and put in hacks so that it
> > > > knows that sometimes some EFI services are not available?  That sounds
> > > > like it's going to make the EFI path just as unmanageable as the
> > > > current PV path.
> > >  
> > > Requiring code in the new entry point to manipulate control registers
> > > and do the switch to long-mode does not seem like a minimal amount of
> > > code to me,
> > > 
> > >   http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00134.html
> > > 
> > > What's likely to happen in the future is that startup_(32|64) will be
> > > entered with different settings depending on whether coming from
> > > HVMlite or bare metal, due to the natural tendency for these kinds of
> > > code paths to diverge.
> > 
> > I hope they do not have the same churn as the rest of Linux code.
> > 
> > The startup_(32|64) are to be called from divergent
> > bootloaders - and they are responsible to set the stage. Or in other
> > words - startup_(32|64) has some expectations of what the world
> > will look like. Changing those means the bootloaders stub have to change
> > too.
> > 
> > But if there is churn it surely is less than what the PV code paths
> > are enforcing now in x86 code.

Its better for sure. But we can also look at other options to make it
even better. Its worth some review at the very least.

> Let me expand on that since I was not sure if I was clear.
> 
> Currently Boris tirelessly ends up fixing on almost every merge window
> Xen related fallout. That is new functionality that breaks Xen.
> He has been doing this for years and before him I was doing it.

FWIW the work I'm doing with linker tables and x86's use of this on
the boot side of things should help avoid these issues proactively.
Sounds too good to be true ? I know. I thought it was rather impossible,
but its what I've come up with and I think it should really help with
that.

This should help either avoid these issues moving forward proactively
to let us keep the old PV path for legacy junk if we want that, or if
we really want to remove the PV path completely and replace it with
HVMLite it should help us avoid issues proactively until we are
ready to nuke the old PV path completely.

So lets say we plan to remove old PV path in 5 years, with the work I'm
doing on the old PV path it means we'll have in place a proactive
framework to avoid Xen fallout *now*, while we churn away towards the
HVMLite lofty goals.

> This is what an maintainer does - and with the HVMLite/PVH stub
> paths that will still continue - that is fallout from the
> startup_(32|64) code changes will be handled as before.

Right, that's because we did not have a proactive solution to
the problem.

> However the bigger goals are that:
>  - This churn will be much much lower than the existing one,
> 
>  - baremetal won't have to deal with some rather odd semantics
>    placed by the pvops paths that are funky and drive x86
>    maintainers to lose hair (amongts other things).

Right on. We are all in strong agreement that the old PV path is a
grand piece of fecal matter.

  Luis

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

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

On Wed, Apr 06, 2016 at 04:02:40PM +0100, Matt Fleming wrote:
[...]
> One place that struck me as suitable for this "hypercall in an EFI
> service stub" approach is the trouble with doing ACPI reboot as
> documented here,
> 
>   http://lists.xen.org/archives/html/xen-devel/2016-02/msg01609.html
> 
> Performing the reset hypercall from within HVMlite's custom EfiReset()
> service would avoid having to touch ACPICA at all, and would be
> indistinguishable from bare metal.

I don't get this, the "reset/shutdown" hypercall requires the following 
steps from Dom0 (it's not as simple as calling a hypercall):

The way to perform a full system power off from Dom0 is different than 
what's done in a DomU guest. In order to perform a power off from Dom0 the 
native ACPI path should be followed, but the guest should not write the 
`SLP_EN` bit to the Pm1Control register. Instead the 
`XENPF_enter_acpi_sleep` hypercall should be used, filling the following 
data in the `xen_platform_op` struct:

    cmd = XENPF_enter_acpi_sleep
    interface_version = XENPF_INTERFACE_VERSION
    u.enter_acpi_sleep.pm1a_cnt_val = Pm1aControlValue
    u.enter_acpi_sleep.pm1b_cnt_val = Pm1bControlValue

At which point it means that we are either going to duplicate ACPICA code 
into the HVMlite's custom EfiReset() service, or we are going to call into 
ACPICA, which is what we already do now.

Roger.

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

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

On Wed, 13 Apr, at 12:03:12PM, Roger Pau Monné wrote:
> 
> I don't get this, the "reset/shutdown" hypercall requires the following 
> steps from Dom0 (it's not as simple as calling a hypercall):
> 
> The way to perform a full system power off from Dom0 is different than 
> what's done in a DomU guest. In order to perform a power off from Dom0 the 
> native ACPI path should be followed, but the guest should not write the 
> `SLP_EN` bit to the Pm1Control register. Instead the 
> `XENPF_enter_acpi_sleep` hypercall should be used, filling the following 
> data in the `xen_platform_op` struct:
> 
>     cmd = XENPF_enter_acpi_sleep
>     interface_version = XENPF_INTERFACE_VERSION
>     u.enter_acpi_sleep.pm1a_cnt_val = Pm1aControlValue
>     u.enter_acpi_sleep.pm1b_cnt_val = Pm1bControlValue
> 
> At which point it means that we are either going to duplicate ACPICA code 
> into the HVMlite's custom EfiReset() service, or we are going to call into 
> ACPICA, which is what we already do now.

Fair enough, I wasn't aware that you needed to call into ACPI to
perform the reset.

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

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

On Wed, Apr 06, 2016 at 12:07:36PM +0100, George Dunlap wrote:
> On Wed, Apr 6, 2016 at 3:40 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> > 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.
> [snip]
> >   * Issues with boot x86 boot entries
> >     * Small x86 zero page stubs
> [snip]
> >   * Points against using EFI
> >     * Nulling the claimed boot loader effect
> 
> I'm a bit confused about this. You list exactly two arguments against
> the proposed stub in the "con" section:
> 1. Bootloaders may not be able to use the extra entry point
> 2. It's an extra entry point
> 
> And then later, in another section, you actually list the reason #1 is
> irrelevant: bootloaders don't matter because the stub is there to boot
> from the Xen hypervisor.

Forgive me, the private thread was ongoing and I really wanted to capture
both sides of the expressed arguments and move to the list any extensions
to the discussion, this meant annotating both positions and letting
others fill in the gaps to determine if in fact one position was really
nullified by the other.

First I should state that it is only natural for anyone sensible to have
any type of knee-jerk reaction to kick and scream about the idea of
adding yet a new x86 entry point for Linux... IMO one should not expect
it to be sensible to simply accept yet-another-entry-point to Linux,
rather is should be the expected behaviour to have people really dig
and ensure they did their homework to ensure that if they are going to
add yet-another-entry-point they really validate and have exhausted
review of all possible avenues.

It was Andrew Coopers's position that boot loaders would not need to be
involved, and that would seem to nullify Matt's original position on this.

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'...

> So the only actual argument you have against the proposed PVH stub in
> the linked document is that it's an extra entry point.

Then you have not really read the document well, more to the point,
EFI's entry already does what the small HVMLite stub does, already
provides an existing entry and path to the kernel, so why should we
add yet another small stub?

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 ?

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. To take this further,
virtualization semantics are being abused even outside of Xen -- drivers
developers may think that just because some semantics are available they can
use them to customize drivers to fine tune them for virtualized environments.
Even the best of our folks have taken positions to claim certain hacks are
*impossible* to change [0], when in fact only 4 days later a completely sensible
replacement was found [1], and this as even outside of Xen's situation, so its
not only Xen I am careful over here with regards to semantics. If we need early
boot code semantics or general kernel semantics for virtualization I want to
address that now and I want to be very careful with that given the abuse.
I'm doing my part to ensure that we clarify sloppy old semantics on Xen [2],
and this effort is actually proving to even pave the path for HVMLite, for
instance consider the gains of leveraging use of the legacy devices struct
in the future for ACPI_FADT_NO_VGA now, which HVMLite's specification seems
to annotate it will use. Clearing out the paravirt_enabled() hack for
pnpbios helped push for a right architectural solution to pave the path
for this in generic fashion.

[0] http://lkml.kernel.org/r/s5hvb4151v1.wl-tiwai@suse.de
[1] https://www.spinics.net/lists/alsa-devel/msg48627.html
[2] http://lkml.kernel.org/r/1459987594-5434-1-git-send-email-mcgrof@kernel.org

> 
> >   * Why use EFI for HVMlite
> >     * EFI calling conventions are standardized
> >     * EFI entry generalizes what new HVMLite entry proposes
> >     * Further semantics may be needed
> >     * Match Xen ARM's clean solution
> >     * You don't need full EFI emulation
> >       * Minimal EFI stubs for guests
> >         * GetMemoryMap()
> >         * ExitBootServices()
> >       * EFI stubs which may be needed for guests
> >         * Exit()
> >         * Variable operation functions
> >       * EFI stubs not needed for guests
> >         * GetTime()/SetTime()
> >         * SetVirtualAddressMap()
> >         * ResetSystem()
> >       * dom0 EFI
> >       * domU EFI emulation possibilities
> >         * Xen implements its own EFI environment for guests
> >         * Xen uses Tianocore / OVMF
> 
> So rather than make a new entry point which does just the minimal
> amount of work to run on a software interface (Xen), you want to take
> an interface designed for hardware (EFI) and put in hacks so that it
> knows that sometimes some EFI services are not available? 

The purpose of the discussion is to evaluate the EFI entry as a possible
alternative candidate to yet another entry point, from a completely engineering
neutral position.

> 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.

  Luis

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

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

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.

(Julien is a Xen ARM maintainer, he can correct me if I've said
something incorrect.)

 -George

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

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

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).

  Luis

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

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

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

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

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

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.

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.

 -George

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

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

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.

> 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.

  Luis

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

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

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.

[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".

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?

>> 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; and your suggestions
for further possibilities (like this one) keep getting more and more
obviously unsuitable.  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.

 -George

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

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

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

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

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

On Wed, Apr 13, 2016 at 12:12:25AM +0200, Luis R. Rodriguez 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 don't see how this is relevant to the conversation that's going on:

How many x86 hardware provide DT? I bet this is 0%.

How many OSes can boot on x86 using DT? Linux maybe, certainly FreeBSD, 
Windows or OpenBSD won't be able to boot at all when provided a DT on x86.

Is Xen going to craft a DT for x86 based on ACPI? No, because it can't parse 
the DSDT or other dynamic tables that contain the information about 
the devices in the system.

I would also like to point out that DT or not DT is not really the problem 
here, the issue that George was trying to point out is that on x86 there's 
some legacy hardware that's considered to be always there, so it's presence 
is not signaled by ACPI, and HVMlite is _not_ emulating this hardware. It 
doesn't matter if the hardware description comes from ACPI or DT, this 
hardware is considered to be always present on PC compatible hardware.

Roger.

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

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

On Wed, Apr 13, 2016 at 12:25:03PM +0200, Roger Pau Monné wrote:
> On Wed, Apr 13, 2016 at 12:12:25AM +0200, Luis R. Rodriguez 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 don't see how this is relevant to the conversation that's going on:

Its relevant as George brought up DT as a *reason* why ARM was able
to cope with no custom entry point...

> How many x86 hardware provide DT?


One. CE4100.

arch/x86/platform/ce4100/falconfalls.dt

> I bet this is 0%.

That's slightly more than 0%.

> How many OSes can boot on x86 using DT? Linux maybe, certainly FreeBSD, 
> Windows or OpenBSD won't be able to boot at all when provided a DT on x86.

You guys seem to be taking these things too personal. 

Let me repeat, my goal is to ensure we review things without a bias. The points
you make here *now* are things I welcome to the discussion as reasons for
ruling out DT as ways to fine tune further semantics, its however by no means
something we should have discarded.

> Is Xen going to craft a DT for x86 based on ACPI?  No, because it can't parse
> the DSDT or other dynamic tables that contain the information about the
> devices in the system.

Again, DT was brought up by George as reason why ARM was able to cope
with no custom entry point. That's all. What you raise is a good point
to highlight but it does not mean we can't use it if we wanted to for
other things, for instance as an alternative to extending the x86 boot
protocol with custom things which we may need to enhance semantics
early in boot. If that is a stupid prospect lets highlight that and
rule it out.

> I would also like to point out that DT or not DT is not really the problem 
> here, the issue that George was trying to point out is that on x86 there's 
> some legacy hardware that's considered to be always there, so it's presence 
> is not signaled by ACPI, and HVMlite is _not_ emulating this hardware. It 
> doesn't matter if the hardware description comes from ACPI or DT, this 
> hardware is considered to be always present on PC compatible hardware.

x86 Xen PV guests are not alone.  I'm adding quirks we can use to address this
in a clean way now which turns out to be very useful for other custom x86
platforms.

  Luis

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

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

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

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?

>   * 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).

Classic PV guests don't have legacy hardware at all, they just have PV 
interfaces, so I'm even less sure of what this means.

Roger.

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

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

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.

I got the impression that if we wanted to remove the old PV path we had to see
if we can address old classic PV x86 guests through HVMlite, otherwise we'd
have to live with the old PV path for the long term.

> >   * 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).
> 
> Classic PV guests don't have legacy hardware at all, they just have PV 
> interfaces, so I'm even less sure of what this means.

Using the terms you use by "Leave legacy stuff on the old PV path" I meant 
not having to address classic PV guest support through HVMLite.

  Luis

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

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

Back to top | Article view | linux.kernel

csiph-web