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
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 :-).
Regards,
Jim