From xen-devel-bounces@lists.xen.org Thu Sep 19 12:11:20 2013 Received: (at maildrop) by bugs.xenproject.org; 19 Sep 2013 11:11:20 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1VMc8m-0005iE-6R for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Thu, 19 Sep 2013 12:11:20 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VMc5z-000269-If; Thu, 19 Sep 2013 11:08:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VMc5y-000264-3D for xen-devel@lists.xenproject.org; Thu, 19 Sep 2013 11:08:26 +0000 Received: from [85.158.139.211:20104] by server-13.bemta-5.messagelabs.com id 18/34-23010-92BDA325; Thu, 19 Sep 2013 11:08:25 +0000 X-Env-Sender: fabio.fantoni@m2r.biz X-Msg-Ref: server-7.tower-206.messagelabs.com!1379588904!3387892!1 X-Originating-IP: [74.125.83.42] X-SpamReason: No, hits=1.7 required=7.0 tests=BIZ_TLD X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11728 invoked from network); 19 Sep 2013 11:08:24 -0000 Received: from mail-ee0-f42.google.com (HELO mail-ee0-f42.google.com) (74.125.83.42) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 19 Sep 2013 11:08:24 -0000 Received: by mail-ee0-f42.google.com with SMTP id b45so4101751eek.29 for ; Thu, 19 Sep 2013 04:08:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FmNjCpoUCJQKLFkIglS8FM+0t/s0dcsvQAe0S3dtHvE=; b=hWmnc/opmkw87kx0zbpsbo8Tol748hYWUjAcMVPOG3kdOf5dnhvC7f6y0g7O3ygVFw flyW8KBUZtUhrxWEDVX2xu4R8Ox3Ril/tVJIsg3s//YN6Ktiu3Aedu5+10ZvoGPrAKqY YJO2e3SBwClcJDclvpQWhfepjYfYkmCwiT4wgvJ3UfDLSOXxLcD7A7uNG8e/+BznjLX1 AeHb5EFJUFUCf1CF0t28vp+tMLd70Yx/lvz8Sl0ognqR7Qv5LsH7Q7OZBv7eu0Yw9uaS B2/Ke/GeUAPBloXto4/dA5TaKKiOpB2owCrec3cbm8BUpb+/HVbRbeQIyTRZ71yU02p4 ANQg== X-Gm-Message-State: ALoCoQnyaFt5CZjdc+d5wAcDzgNVuLBgJF0NXlayGhZtPKA8cdzpab8W5FRdakzm/UgoWeFQAlDb X-Received: by 10.15.107.10 with SMTP id ca10mr1545089eeb.76.1379588904161; Thu, 19 Sep 2013 04:08:24 -0700 (PDT) Received: from [192.168.1.26] (ip-73-126.sn2.eutelia.it. [83.211.73.126]) by mx.google.com with ESMTPSA id bn13sm10389779eeb.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 04:08:23 -0700 (PDT) Message-ID: <523ADB2F.3000003@m2r.biz> Date: Thu, 19 Sep 2013 13:08:31 +0200 From: Fabio Fantoni User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: George Dunlap 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> Cc: Andrew Cooper , "qemu-devel@nongnu.org" , Keir Fraser , Jan Beulich , Anthony PERARD , xen-devel Subject: Re: [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel