[libvirt] [PATCH v3 2/5] libxl: add support for PVH

Jim Fehlig jfehlig at suse.com
Wed Oct 3 21:13:30 UTC 2018


On 10/2/18 4:50 PM, Jim Fehlig wrote:
> On 9/30/18 8:15 PM, Marek Marczykowski-Górecki wrote:
>> Since this is something between PV and HVM, it makes sense to put the
>> setting in place where domain type is specified.
>> To enable it, use <os><type machine="xenpvh">...</type></os>. It is
>> also included in capabilities.xml, for every supported HVM guest type - it
>> doesn't seems to be any other requirement (besides new enough Xen).
>>
>> Signed-off-by: Marek Marczykowski-Górecki <marmarek at invisiblethingslab.com>
>> ---
>> Changes in v2 proposed by Jim:
>>   - use new_arch_added var instead of i == nr_guest_archs for clarity
>>   - improve comment
>>   - adjust for now required Xen >= 4.6 (remove part for Xen < 4.5)
>>
>> Changes in v3:
>>   - limit VIR_DOMAIN_OSTYPE_XEN -> VIR_DOMAIN_OSTYPE_LINUX conversion to
>>   Xen PV only
>>   - do not accept VIR_DOMAIN_OSTYPE_LINUX for PVH
>>   - fix reported capabilities for PVH - remove hostdev passthrough and
>>   video/graphics
> 
> No video, graphics or hostdev passthrough - bummer. Begs the question: what to 
> do with PVH XML config containing these devices? Reject it? Silently ignore? 
> I'll also need to remember to enable these as PVH gains support for the devices.
> 
>>   - use #ifdef LIBXL_DOMAIN_TYPE_PVH instead of hypervisor version to
>>   check for PVH support
> 
> This is a much better approach than the version check. I should have thought of 
> that earlier, sorry.

Actually it is not. LIBXL_DOMAIN_TYPE_PVH is a value in the enum 
libxl_domain_type. Too bad PVH support isn't advertised in libxl.h with 
something like LIBXL_HAVE_PVH. Looks like we are stuck with the version check :-(.

Regards,
Jim




More information about the libvir-list mailing list