Re: [Xen-devel] [PATCH] libxl: Implement basic video device selection

[Jim Fehlig <jfehlig@xxxxxxxx>]

Stefan Bader wrote:
> On 16.07.2014 23:05, Jim Fehlig wrote:
>   
>> While testing this, I noticed that libvirt will set vram to 9216 if not
>> specified.  E.g.
>>
>> # cat test.xml
>> ...
>>     <video>
>>       <model type='vga'/>
>>     </video>
>> ...
>> # virsh define test.xml
>> # virsh dumpxml test
>> ...
>>     <video>
>>       <model type='vga' vram='9216' heads='1'/>
>>     </video>
>> ...
>>
>> With type='vga', libxl will then fail to start the domain
>>
>> libxl: error: libxl_create.c:253:libxl__domain_build_info_setdefault:
>> videoram must be at least 16 MB for STDVGA on QEMU_XEN
>>     
>
> Heh, thats "funny". At least this was the same thing I observed when creating
> new guests with virt-manager. Maybe I blamed the wrong part of the stack. Or
> they both do it. This lead the the second part of my changes which was not so
> clear about whether it should or should not go upstream.
>
> So from my side a fixup of some kind would be good but we can work on this in 
> a
> follow-up.
>   

The problem is, some domains may not start after applying this patch. 
Consider a domain with the following video config

    <video>
      <model type='vga' vram='9216' heads='1'/>
    </video>

This would work pre-patch since libxl_domain_build_info->video_memkb
would be initialized to LIBXL_MEMKB_DEFAULT when calling
libxl_domain_build_info_init().  But the domain will fail to start
post-patch since video_memkb is set to an invalid value.

I know the current behavior is not correct either, but would be nice to
fix everything up in one series.  I started on a second patch that would
validate input or set sane defaults in libxlDomainDeviceDefPostParse(),
but while testing realized that sane defaults depend on which qemu is
used.  E.g. the minimum video_memkb values have doubled with QEMU_XEN vs
QEMU_XEN_TRADITIONAL - see $xen_root/tools/libxl/libxl_create.c,
libxl__domain_build_info_setdefault().  [I'll mention again that it is
unfortunate that QEMU_XEN vs QEMU_XEN_TRADITIONAL leaked through the
public API.]

I'm thinking of writing a utility function to detect the old vs new
qemu, hoping there is something in the help output or similar to
determine which one <emulator> is.  Such a function would be useful for
David Scott's old patch to support arbitrary user-provided <emulator>

https://www.redhat.com/archives/libvir-list/2013-April/msg02119.html

But alas, this will have to wait until I return from vacation.

Regards,
Jim



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel