Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release

[Fabio Fantoni <fabio.fantoni@m2r.biz>]

Il 19/09/2013 12:04, George Dunlap ha scritto:
> On 19/09/13 11:01, Jan Beulich wrote:
>>>>> On 19.09.13 at 11:22, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>> This is logs from xl dmesg about Quantal (ubuntu 12.10) hvm domU with
>>> qxl vga and patch "x86-HVM-emul-split-large":
>>>
>>>> (d3) HVM Loader
>>>> [...]
>> So in particular no wrong mmio size messages.
>>
>>> qemu seem to crash at domU's xorg loading, nothing on logs about the
>>> crash, only the last line added on xl dmesg above and on qemu log:
>>> qemu: terminating on signal 1 from pid 8485
>>>
>>> I found strange things on xl dmesg logs above about domU (I put it in
>>> bold and starred).
>> I can't say anything about those. Once again, with qemu issues
>> (and tools ones in general) i have to defer to the respective
>> experts.
>
> Fabio,
>
> I think back when Anthony Perard looked at this, he found that there 
> was a field not being initialized in qemu that caused it to crash when 
> using qxl.  I think the fix was just a one-line patch -- do you have 
> that patch applied to your copy of qemu?
>
>  -George

Thanks for reply.
The anthony fix was accepted time ago on qemu git:
http://git.qemu.org/?p=qemu.git;a=commit;h=329f97fc4ff4b533fcd2d8f4eab6c9c2568aed27
I use qemu 1.6 that include also this patch on my latest tests.

About the bold line on xl dmesg of previous mail, (relative to 
xen/arch/x86/hvm/stdvga.c) I think that could be cause of potential 
problem with qxl which has different hardware structures, but I not have 
sufficent knownoledge about to found if this need a change and where.

About qxl hardware structure information I found only this details on 
qemu mailing list time ago:
> The qxl device has two large memory regions:
>
> Region #1 is called "ram" and is mapped to PCI bar 0.  This is again
> splitted into three parts:  The framebuffer at the start, the command
> rings at the end, and storage area for spice rendering commands and
> image data inbetween.
>
> Region #2 is called "vram".  This is storage for images, called
> "surfaces" in spice.  Surfaces can be both source and target for spice
> rendering operations.  X11 can store offscreen pixmaps there for
> example.  Once qxl gets 3D support surfaces can also be used for textures.
>
> Now for the properties:
>
> vgamem_mb
>    specifies the size of the framebuffer portion of the "ram" region, in
>    megabytes.  Must be big enougth to hold the maximum display
>    resolution you want to use.  Replaces the fixed VGA_RAM_SIZE define.
>    Default is 8 or 16 MB depending on machine type with all patches of
>    this series applied (see last patch).
>
> ram_size_mb
>    specifies the total size of the "ram" region, in megabytes.  Defaults
>    to 64 MB.  Must be larger than vgamem_mb obviously.
>
> vram_size_mb
>    specifies the total size of the "vram" region, in megabytes.
>    Defaults to 64 MB.
>
> vram64_size_mb
>    if this one is present and larger than vram_size_mb qxl will get an
>    additional 64bit pci bar.  Both 32bit and 64bit vram pci bars are
>    backed by the "vram" memory region, the 32bit bar is an alias mapping
>    for the first part of the 64bit pci bar.  This can be used to give
>    guests *lots* of vram without exhausting 32bit pci address space.
>    Obviously only useful for 64bit guests.  Requires cutting edge
>    seabios to get the 64bit bar actually mapped above 4G.
>
> ram_size
>    specifies the total size of the "ram" region, in bytes.  For
>    compatibility with older qemu versions, ignored if ram_size_mb
>    property is present.
>
> vram_size
>    specifies the total size of the "vram" region, in bytes.  For
>    compatibility with older qemu versions, ignored if vram_size_mb
>    property is present.
i hope this can help to understand if is needed other change on xen side.

Thanks for any reply.