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

[Luis R. Rodriguez]

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