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

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

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

No. We need to deprecate the PV paths - and the agreement we hammered out
with the x86 maintainers was that once PVH/HVMLite is stable the clock
would start ticking on PV (pvops) life. All the big users of PV Linux
were told in persons to prep them for this.

Keep in mind that this is not for deleting of support in hypervisor for
PV hypercalls - meaning you would still be able to run say 2.6.18 RHEL5
in years to come. It is just that Linux v6.1 won't have any more PV paths
and can only run in HVM or PVH/HVMLite mode under Xen.

> 
> > >   * 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
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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