Re: HVMLite / PVHv2 - using x86 EFI boot entry

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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.

And it is in assembler so only a few folks would venture in that..


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

Why? You can use GRUB2+EFI+MB2 and boot with EFI boot services..
Or boot Xen as an EFI application.
> 
> 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.

.. Pragmatic! I like that!

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