[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |