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