[libvirt] [PATCH v2 0/8] libxl: PVHv2 support

[Marek Marczykowski-Górecki]

On Mon, Sep 24, 2018 at 05:09:44PM -0600, Jim Fehlig wrote:
> On 9/18/18 6:50 PM, Marek Marczykowski-Górecki wrote:
> > This is a respin of my old PVHv1 patch[1], converted to PVHv2.
> > Should the code use "PVH" name (as libxl does internally), or "PVHv2" as in
> > many places in Xen documentation? I've chosen the former, but want to confirm
> > it.
> 
> From libvirt's perspective it should be "PVH". If anything, the Xen
> documentation should change. AFAIK the various PVH attempts/names (PVHv1,
> hvmlite, PVHv2, ...) have merged to simply be known as "PVH".
> 
> > 
> > Also, not sure about VIR_DOMAIN_OSTYPE_XENPVH (as discussed on PVHv1 patch) -
> > while it will be messy in many cases, there is
> > libxl_domain_build_info.u.{hvm,pv,pvh} which would be good to not mess up.
> > Also, PVHv2 needs different kernel features than PV (CONFIG_XEN_PVH vs
> > CONFIG_XEN_PV), so keeping the same VIR_DOMAIN_OSTYPE_XEN could be
> > confusing.
> > On the other hand, libxl_domain_build_info.u.pv is used in very few places (one
> > section of libxlMakeDomBuildInfo), so guarding u.hvm access with
> > VIR_DOMAIN_OSTYPE_HVM may be enough.
> > For now I've reused VIR_DOMAIN_OSTYPE_XEN - in the driver itself, most of
> > the code is the same as for PV.
> 
> I should have read your v1 cover letter closer and agreed on the approach
> before spending time looking at code :-). But in the end I still think the
> OS type is VIR_DOMAIN_OSTYPE_XEN with the machine attribute specifying PV vs
> PVH. I use the fact that both OS types are modified to run on Xen to
> rationalize using VIR_DOMAIN_OSTYPE_XEN for both. Perhaps it would be best
> for a third opinion and Daniel (cc'd) can chime in.
> 
> > Since PVHv2 relies on features in newer Xen versions, I needed to convert also
> > some older code. For example b_info->u.hvm.nested_hvm was deprecated in favor
> > of b_info->nested_hvm. While the code do handle both old and new versions
> > (obviously refusing PVHv2 if Xen is too old), this isn't the case for tests.
> > How it should be handled, if at all?
> 
> Due to the compilation error in patch 5, I haven't checked patches 6-8 on
> xen < 4.9, which may help me understand the problem you describe. Sorry it
> is not obvious to me from the reading.

You can already observe the problem after applying "libxl: prefer new
location of nested_hvm in libxl_domain_build_info".

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180929/8995b8b9/attachment-0001.sig>