From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Xen 4.3 development update RC2 imminent Date: Wed, 22 May 2013 16:05:27 +0100 Message-ID: <519CDEB7.5090608@eu.citrix.com> References: <519B7F67.2050602@citrix.com> <519B8541.8090505@citrix.com> <519BA6F302000078000D7CF2@nat28.tlf.novell.com> <519B9D15.7060004@eu.citrix.com> <519B9DF9.7090303@eu.citrix.com> <519CBEF3.4020701@m2r.biz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <519CBEF3.4020701@m2r.biz> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Fabio Fantoni Cc: Anthony PERARD , Andrew Cooper , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 22/05/13 13:49, Fabio Fantoni wrote: > Il 21/05/2013 18:16, George Dunlap ha scritto: >> On 05/21/2013 05:13 PM, George Dunlap wrote: >>> On 05/21/2013 03:55 PM, Jan Beulich wrote: >>>>>>> On 21.05.13 at 16:31, Andrew Cooper >>>>>>> wrote: >>>>> On 21/05/13 15:06, Anthony PERARD wrote: >>>>>> But then, once this applied, qxl is still not able to start. Xorg >>>>>> crash >>>>>> (in the guest), and here is why: >>>>>> >>>>>> (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 >>>>>> (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 >>>>> >>>>> Disassembly of section .data: >>>>> >>>>> 0000000000000000 <.data>: >>>>> 0: f3 0f 6f 19 movdqu (%rcx),%xmm3 >>>>> >>>>> Xen does not support emulating SSE instructions. We have >>>>> sporadically >>>>> seen similar errors from Windows guests. The best guess I have >>>>> managed >>>>> to get so far is that %rcx is a pointer to something which Xen >>>>> thinks is >>>>> an MMIO page. >>>>> >>>>> In this case, it looks like X is copying from MMIO into an xmm >>>>> register, >>>>> scraping the framebuffer perhaps? In the windows failure, it was the >>>>> pagescrub trying to zero ram, which clearly indicated something >>>>> wonky in >>>>> the combined idea of the memory map. >>>>> >>>>> If Spice is doing something valid and sensible, then Xen will likely >>>>> need extending to be able to emulate SSE instructions. >>>> >>>> The emulator in the hypervisor can handle simple SSE instructions >>>> like the above quite well. It's not immediately clear to me why >>>> hvmemul_do_io() would need to limit the size to no more than a >>>> long's width. Perhaps the data passing to the device model may >>>> need adjustment to accommodate wider entities... >>> >>> Hmm, but the code seems to indicate that the DM can handle wider >>> entities, by "reading all ones": >>> >>> if ( dir == IOREQ_READ ) >>> memset(p_data, ~0, size); >>> >>> Anthony, do you want to try making that size check one size bigger >>> (e.g., allow it to be 16 or 32)? >> >> No, that obviously won't work, because of the line just following: >> >> if ( (p_data != NULL) && (dir == IOREQ_WRITE) ) >> { >> memcpy(&value, p_data, size); >> p_data = NULL; >> } >> >> >> value is of size "long", so this won't work. >> >> -George > Thanks for help to solve this problem. > Are there news about? > > Probably this is a stupid question: is this patch related to that > problem? > http://lists.xen.org/archives/html/xen-devel/2013-05/msg02142.html No, I'm afraid that has nothing to do with this issue. I've only looked briefly at it, but it appears that the interface between Xen and qemu is limited to MMIO accesses of 8 bytes; changing that interface is not something we can really do while we're in the middle of doing a release. The only work-around that would be suitable for 4.3 would be if we could find an option to tell the X server not to execute SSE instructions. If there is no such work-around, then I'm afraid we're going to have to disable the interface for 4.3. We'll put it on the list of work items for 4.4. -George