[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC] tools/libxl: Switch Arm guest type to PVH



On Tue, 3 Jul 2018, Roger Pau Monné wrote:
> On Mon, Jul 02, 2018 at 10:18:17AM -0700, Stefano Stabellini wrote:
> > On Mon, 2 Jul 2018, Julien Grall wrote:
> > > On 06/26/2018 07:49 AM, Roger Pau Monné wrote:
> > > > On Mon, Jun 25, 2018 at 05:39:12PM +0100, Ian Jackson wrote:
> > > > > Roger Pau Monné writes ("Re: [PATCH RFC] tools/libxl: Switch Arm guest
> > > > > type to PVH"):
> > > > > > IMO I would remove the 'type' option from xl.cfg (so that it's
> > > > > > basically ignored) in the ARM case and force it internally to PVH 
> > > > > > (if
> > > > > > that's the best route for current ARM guests).
> > > > > 
> > > > > What about libvirt users ?  I haven't seen what a libvirt Xen ARM
> > > > > guest config looks like but we need to meak sure that existing guests
> > > > > don't break.
> > > > 
> > > > For livbirt (or users of libxl library) we could force the type to
> > > > pvh, regardless of the value set by the client, but I guess that would
> > > > make adding types later on quite complicated.
> > > 
> > > I am fairly confident we will never have PV guest on Arm. So one solution
> > > would be to alias PV to PVH for Arm. This still give us the liberty to add
> > > more guest type in the future.
> > > 
> > > Any opinions?
> > 
> > Roger, what is the plan for x86? Wasn't there an idea to silently and
> > transparently "upgrade" PV guests to PVH when possible (when hardware
> > support is available)?
> 
> This could only be done for xl config files that don't specify a
> 'type' option IMO, for libvirt and other users of libxl I don't think
> this is feasible.
> 
> > If that is the case, basically we could do the same for ARM. We could
> > have an hardware features check, that would always return true on ARM
> > because without virtualization extensions Xen cannot even boot, then
> > upgrade PV to PVH. On x86 the upgrade would only happen when the
> > required features are present.
> 
> It's slightly more convoluted on x86 because apart from the hardware
> features you also need to parse the kernel in order to figure out if
> it has the PVH entry point before setting the type to PVH.

I see. Too bad. In that case, if we have to go with an ARM specific
solution and nobody has a better suggestion, then I think it is OK to go
ahead with aliasing PV to PVH on ARM as Julien mentioned.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.