[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |