[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@xxxxxxx> 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.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.