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?
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list