From xen-devel-bounces@lists.xen.org Fri Jul 05 18:01:09 2013 Received: (at maildrop) by bugs.xenproject.org; 5 Jul 2013 17:01:09 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1Uv9Nd-0008QU-Gi for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Fri, 05 Jul 2013 18:01:09 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Uv9Lw-0004FM-N1; Fri, 05 Jul 2013 16:59:24 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Uv9Lv-0004FH-GR for xen-devel@lists.xen.org; Fri, 05 Jul 2013 16:59:23 +0000 Received: from [85.158.136.67:35579] by server-4.bemta-5.messagelabs.com id 0E/B0-17085-A6BF6D15; Fri, 05 Jul 2013 16:59:22 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-9.tower-207.messagelabs.com!1373043561!20846466!1 X-Originating-IP: [74.125.82.169] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4972 invoked from network); 5 Jul 2013 16:59:21 -0000 Received: from mail-we0-f169.google.com (HELO mail-we0-f169.google.com) (74.125.82.169) by server-9.tower-207.messagelabs.com with RC4-SHA encrypted SMTP; 5 Jul 2013 16:59:21 -0000 Received: by mail-we0-f169.google.com with SMTP id n57so2165302wev.0 for ; Fri, 05 Jul 2013 09:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=t53oqONu9MjVcm/j6kXO9igJmSoEso4Jr+WmJsFEwk4=; b=QjC+g0A/YvYsEyA+b9p4g+ofrxx1ER8ZC9RWyBHyl5Nr1NE557SWCnH187PrXQPdb5 pMBEfgd4r1VBGmsOQjfc6C+9MeVmocSCJmxlB1wnIn9u4AgObgPtsQwlGCVWkE37fdjJ OKeduc+6Z7DC+jVPpygYjwThFrlrtTkdUwjgdVSU13OZWndgXV8IQYXoVa7FEMu6sD6/ 0/7qEisTYVPpgcCTBLc4+2s2o2JWQMEaxF4t+Gxq+aaN1R+Fc5kcZ9PUp3/xK5+1G44+ 7/e6w+R+CZxeHMVY//JdXv/PlHw8Ann8b5mTmVWmusHcvdSXolahlA3q8DGxOHVSMXYP Ou2w== MIME-Version: 1.0 X-Received: by 10.194.84.205 with SMTP id b13mr6401920wjz.92.1373043561580; Fri, 05 Jul 2013 09:59:21 -0700 (PDT) Received: by 10.194.92.104 with HTTP; Fri, 5 Jul 2013 09:59:21 -0700 (PDT) In-Reply-To: <51A68060.7010500@citrix.com> References: <1369813427.22605.38.camel@dagon.hellion.org.uk> <51A68060.7010500@citrix.com> Date: Fri, 5 Jul 2013 17:59:21 +0100 X-Google-Sender-Auth: xbfxnwEBIA4dmlRKoaYNa37-MGM Message-ID: From: George Dunlap To: Andrew Cooper Cc: Fabio Fantoni , Keir Fraser , Jan Beulich , "xen-devel@lists.xen.org" 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Wed, May 29, 2013 at 11:25 PM, Andrew Cooper wrote: > On 29/05/2013 08:43, Ian Campbell wrote: >> On Tue, 2013-05-28 at 19:09 +0100, Keir Fraser wrote: >>> On 28/05/2013 17:51, "Ian Jackson" wrote: >>> >>>> George Dunlap writes ("[PATCH] libxl: Remove qxl support for the 4.3 >>>> release"): >>>>> The qxl drivers for Windows and Linux end up calling instructions >>>>> that cannot be used for MMIO at the moment. Just for the 4.3 release, >>>>> remove qxl support. >>>>> >>>>> This patch should be reverted as soon as the 4.4 development window opens. >>>>> >>>>> The issue in question: >>>>> >>>>> (XEN) emulate.c:88:d18 bad mmio size 16 >>>>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f >>>>> 19 41 83 e8 403 >>>>> >>>>> The instruction in question is "movdqu (%rcx),%xmm3". Xen knows how >>>>> to emulate it, but unfortunately %xmm3 is 16 bytes long, and the interface >>>>> between Xen and qemu at the moment would appear to only allow MMIO accesses >>>>> of 8 bytes. >>>>> >>>>> It's too late in the release cycle to find a fix or a workaround. >>>> Acked-by: Ian Jackson >>> It could be plumbed through hvmemul_do_io's multi-cycle read/write logic, >>> and done as two 8-byte cycles to qemu. This would avoid bloating the ioreq >>> structure that communicates to qemu. >> Are you proposing we do this for 4.3? I'm not sure how big that change >> would be in terms of impact (just that one instruction, any 16 byte >> operand?). >> >> Of course even if we did this for 4.3 we don't know what the next issue >> will be with QXL. >> >> Ian. > > Furthermore, AVX instruction emulation would require support for 32byte > operands. I don't see the multi-cycle logic scaling sensibly. Andrew, Keir, Jan, does any one of you fancy taking this on for 4.4? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel