From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMc62-0007J4-Kk for qemu-devel@nongnu.org; Thu, 19 Sep 2013 07:08:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMc5x-0005Ej-AY for qemu-devel@nongnu.org; Thu, 19 Sep 2013 07:08:30 -0400 Received: from mail-ea0-f169.google.com ([209.85.215.169]:59293) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMc5x-0005EX-1I for qemu-devel@nongnu.org; Thu, 19 Sep 2013 07:08:25 -0400 Received: by mail-ea0-f169.google.com with SMTP id k11so4142269eaj.28 for ; Thu, 19 Sep 2013 04:08:24 -0700 (PDT) Message-ID: <523ADB2F.3000003@m2r.biz> Date: Thu, 19 Sep 2013 13:08:31 +0200 From: Fabio Fantoni MIME-Version: 1.0 References: <52397B4C02000078000F43F7@nat28.tlf.novell.com> <52399CA2.6030701@m2r.biz> <5239BBBB02000078000F4565@nat28.tlf.novell.com> <5239B4B9.8000604@m2r.biz> <5239D52602000078000F46B7@nat28.tlf.novell.com> <5239C616.8000507@m2r.biz> <5239E46802000078000F4764@nat28.tlf.novell.com> <523AC243.1050406@m2r.biz> <523AE7AB02000078000F4A15@nat28.tlf.novell.com> <523ACC26.6030307@eu.citrix.com> In-Reply-To: <523ACC26.6030307@eu.citrix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: George Dunlap Cc: Andrew Cooper , "qemu-devel@nongnu.org" , Keir Fraser , Jan Beulich , Anthony PERARD , xen-devel 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 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.