[libvirt] [PATCH] libxl: fix default vram setting for implicit video device

[Joao Martins]

On 05/11/2016 11:21 PM, Jim Fehlig wrote:
> On 05/11/2016 05:22 AM, Joao Martins wrote:
>> On 05/11/2016 06:01 AM, Jim Fehlig wrote:
>>> Commit 6879be48 moved adding of an implicit video device after XML
>>> parsing. As a result, libxlDomainDeviceDefPostParse() is no longer
>>> called to set the default vram when adding an implicit device.
>>> Commit 6879be48 assumes virDomainVideoDefaultRAM() will set the
>>> default vram, but it returns 0 if the domain virtType is
>>> VIR_DOMAIN_VIRT_XEN. Attempting to start an HVM domain with vram=0
>>> results in
>>>
>>> error: unsupported configuration: videoram must be at least 4MB for CIRRUS
>>>
>>> The default vram setting for Xen HVM domains depends on the device
>>> model used (qemu-xen vs qemu-traditional), hence setting the
>>> default is deferred to libxlDomainDeviceDefPostParse().
>>>
>>> This patch addresses the problem during creation of the video
>>> device. If vram is 0, it is assumed unset and the default
>>> (depending on qemu-xen vs qemu-traditional) is applied.
>> Hmm, What about letting (xen) libxl decide that? If vram is set to 0 we would
>> set video_memkb to LIBXL_MEMKB_DEFAULT and have (xen) libxl decide the defaults
>> and latter update def with the value libxl set back?
> 
> Yeah, that sounds like a good cleanup for the existing code. But I think fixing
> the logic broken by commit 6879be48 is also in order, which Jan has kindly done
> in place of this hack
> 
> https://www.redhat.com/archives/libvir-list/2016-May/msg00728.html
> 
Yeap, I saw it shortly after my reply.

>>  Altough these values are
>> well established defaults, these might change on libxl in which case prevent
>> domain creation.
> 
> Yep. Good reason for a follow-up patch along the lines of your suggestion :-).
Ah, sounds good!

> 
> Regards,
> Jim
>