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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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.

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.

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.

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


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