All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
@ 2013-09-18  8:07 Jan Beulich
  2013-09-18 12:29 ` Fabio Fantoni
  2013-09-19 10:09 ` George Dunlap
  0 siblings, 2 replies; 31+ messages in thread
From: Jan Beulich @ 2013-09-18  8:07 UTC (permalink / raw)
  To: Fabio Fantoni; +Cc: George Dunlap, Andrew Cooper, Keir Fraser, xen-devel

[-- Attachment #1: Type: text/plain, Size: 2264 bytes --]

>>> On 16.09.13 at 16:10, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
> Il 05/07/2013 18:59, George Dunlap ha scritto:
>> On Wed, May 29, 2013 at 11:25 PM, Andrew Cooper
>> <andrew.cooper3@citrix.com> 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" <Ian.Jackson@eu.citrix.com> 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 <ian.jackson@eu.citrix.com>
>>>>> 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?
> 
> Is there someone that can add full support for SSE on hvm domUs?
> Thanks for any reply.

Mind giving the attached patch a try?

Jan


[-- Attachment #2: x86-HVM-emul-split-large.patch --]
[-- Type: text/plain, Size: 6729 bytes --]

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -438,6 +438,7 @@ static int __hvmemul_read(
 {
     struct vcpu *curr = current;
     unsigned long addr, reps = 1;
+    unsigned int off, chunk = min_t(unsigned int, bytes, sizeof(long));
     uint32_t pfec = PFEC_page_present;
     struct hvm_vcpu_io *vio = &curr->arch.hvm_vcpu.hvm_io;
     paddr_t gpa;
@@ -447,16 +448,38 @@ static int __hvmemul_read(
         seg, offset, bytes, &reps, access_type, hvmemul_ctxt, &addr);
     if ( rc != X86EMUL_OKAY )
         return rc;
+    off = addr & (PAGE_SIZE - 1);
+    /*
+     * We only need to handle sizes actual instruction operands can have. All
+     * such sizes are either powers of 2 or the sum of two powers of 2. Thus
+     * picking as initial chunk size the largest power of 2 not greater than
+     * the total size will always result in only power-of-2 size requests
+     * issued to hvmemul_do_mmio() (hvmemul_do_io() rejects non-powers-of-2).
+     */
+    while ( chunk & (chunk - 1) )
+        chunk &= chunk - 1;
+    if ( off + bytes > PAGE_SIZE )
+        while ( off & (chunk - 1) )
+            chunk >>= 1;
 
     if ( unlikely(vio->mmio_gva == (addr & PAGE_MASK)) && vio->mmio_gva )
     {
-        unsigned int off = addr & (PAGE_SIZE - 1);
         if ( access_type == hvm_access_insn_fetch )
             return X86EMUL_UNHANDLEABLE;
         gpa = (((paddr_t)vio->mmio_gpfn << PAGE_SHIFT) | off);
-        if ( (off + bytes) <= PAGE_SIZE )
-            return hvmemul_do_mmio(gpa, &reps, bytes, 0,
-                                   IOREQ_READ, 0, p_data);
+        while ( (off + chunk) <= PAGE_SIZE )
+        {
+            rc = hvmemul_do_mmio(gpa, &reps, chunk, 0, IOREQ_READ, 0, p_data);
+            if ( rc != X86EMUL_OKAY || bytes == chunk )
+                return rc;
+            addr += chunk;
+            off += chunk;
+            gpa += chunk;
+            p_data += chunk;
+            bytes -= chunk;
+            if ( bytes < chunk )
+                chunk = bytes;
+        }
     }
 
     if ( (seg != x86_seg_none) &&
@@ -473,14 +496,32 @@ static int __hvmemul_read(
         return X86EMUL_EXCEPTION;
     case HVMCOPY_unhandleable:
         return X86EMUL_UNHANDLEABLE;
-    case  HVMCOPY_bad_gfn_to_mfn:
+    case HVMCOPY_bad_gfn_to_mfn:
         if ( access_type == hvm_access_insn_fetch )
             return X86EMUL_UNHANDLEABLE;
-        rc = hvmemul_linear_to_phys(
-            addr, &gpa, bytes, &reps, pfec, hvmemul_ctxt);
-        if ( rc != X86EMUL_OKAY )
-            return rc;
-        return hvmemul_do_mmio(gpa, &reps, bytes, 0, IOREQ_READ, 0, p_data);
+        rc = hvmemul_linear_to_phys(addr, &gpa, chunk, &reps, pfec,
+                                    hvmemul_ctxt);
+        while ( rc == X86EMUL_OKAY )
+        {
+            rc = hvmemul_do_mmio(gpa, &reps, chunk, 0, IOREQ_READ, 0, p_data);
+            if ( rc != X86EMUL_OKAY || bytes == chunk )
+                break;
+            addr += chunk;
+            off += chunk;
+            p_data += chunk;
+            bytes -= chunk;
+            if ( bytes < chunk )
+                chunk = bytes;
+            if ( off < PAGE_SIZE )
+                gpa += chunk;
+            else
+            {
+                rc = hvmemul_linear_to_phys(addr, &gpa, chunk, &reps, pfec,
+                                            hvmemul_ctxt);
+                off = 0;
+            }
+        }
+        return rc;
     case HVMCOPY_gfn_paged_out:
         return X86EMUL_RETRY;
     case HVMCOPY_gfn_shared:
@@ -537,6 +578,7 @@ static int hvmemul_write(
         container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
     struct vcpu *curr = current;
     unsigned long addr, reps = 1;
+    unsigned int off, chunk = min_t(unsigned int, bytes, sizeof(long));
     uint32_t pfec = PFEC_page_present | PFEC_write_access;
     struct hvm_vcpu_io *vio = &curr->arch.hvm_vcpu.hvm_io;
     paddr_t gpa;
@@ -546,14 +588,30 @@ static int hvmemul_write(
         seg, offset, bytes, &reps, hvm_access_write, hvmemul_ctxt, &addr);
     if ( rc != X86EMUL_OKAY )
         return rc;
+    off = addr & (PAGE_SIZE - 1);
+    /* See the respective comment in __hvmemul_read(). */
+    while ( chunk & (chunk - 1) )
+        chunk &= chunk - 1;
+    if ( off + bytes > PAGE_SIZE )
+        while ( off & (chunk - 1) )
+            chunk >>= 1;
 
     if ( unlikely(vio->mmio_gva == (addr & PAGE_MASK)) && vio->mmio_gva )
     {
-        unsigned int off = addr & (PAGE_SIZE - 1);
         gpa = (((paddr_t)vio->mmio_gpfn << PAGE_SHIFT) | off);
-        if ( (off + bytes) <= PAGE_SIZE )
-            return hvmemul_do_mmio(gpa, &reps, bytes, 0,
-                                   IOREQ_WRITE, 0, p_data);
+        while ( (off + chunk) <= PAGE_SIZE )
+        {
+            rc = hvmemul_do_mmio(gpa, &reps, chunk, 0, IOREQ_WRITE, 0, p_data);
+            if ( rc != X86EMUL_OKAY || bytes == chunk )
+                return rc;
+            addr += chunk;
+            off += chunk;
+            gpa += chunk;
+            p_data += chunk;
+            bytes -= chunk;
+            if ( bytes < chunk )
+                chunk = bytes;
+        }
     }
 
     if ( (seg != x86_seg_none) &&
@@ -569,12 +627,29 @@ static int hvmemul_write(
     case HVMCOPY_unhandleable:
         return X86EMUL_UNHANDLEABLE;
     case HVMCOPY_bad_gfn_to_mfn:
-        rc = hvmemul_linear_to_phys(
-            addr, &gpa, bytes, &reps, pfec, hvmemul_ctxt);
-        if ( rc != X86EMUL_OKAY )
-            return rc;
-        return hvmemul_do_mmio(gpa, &reps, bytes, 0,
-                               IOREQ_WRITE, 0, p_data);
+        rc = hvmemul_linear_to_phys(addr, &gpa, chunk, &reps, pfec,
+                                    hvmemul_ctxt);
+        while ( rc == X86EMUL_OKAY )
+        {
+            rc = hvmemul_do_mmio(gpa, &reps, chunk, 0, IOREQ_WRITE, 0, p_data);
+            if ( rc != X86EMUL_OKAY || bytes == chunk )
+                break;
+            addr += chunk;
+            off += chunk;
+            p_data += chunk;
+            bytes -= chunk;
+            if ( bytes < chunk )
+                chunk = bytes;
+            if ( off < PAGE_SIZE )
+                gpa += chunk;
+            else
+            {
+                rc = hvmemul_linear_to_phys(addr, &gpa, chunk, &reps, pfec,
+                                            hvmemul_ctxt);
+                off = 0;
+            }
+        }
+        return rc;
     case HVMCOPY_gfn_paged_out:
         return X86EMUL_RETRY;
     case HVMCOPY_gfn_shared:

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-18  8:07 [PATCH] libxl: Remove qxl support for the 4.3 release Jan Beulich
@ 2013-09-18 12:29 ` Fabio Fantoni
  2013-09-18 12:42   ` Jan Beulich
  2013-09-19 10:09 ` George Dunlap
  1 sibling, 1 reply; 31+ messages in thread
From: Fabio Fantoni @ 2013-09-18 12:29 UTC (permalink / raw)
  To: Jan Beulich; +Cc: George Dunlap, Andrew Cooper, Keir Fraser, xen-devel

Il 18/09/2013 10:07, Jan Beulich ha scritto:
>>>> On 16.09.13 at 16:10, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>> Il 05/07/2013 18:59, George Dunlap ha scritto:
>>> On Wed, May 29, 2013 at 11:25 PM, Andrew Cooper
>>> <andrew.cooper3@citrix.com> 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" <Ian.Jackson@eu.citrix.com> 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 <ian.jackson@eu.citrix.com>
>>>>>> 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?
>> Is there someone that can add full support for SSE on hvm domUs?
>> Thanks for any reply.
> Mind giving the attached patch a try?
>
> Jan
>

Thanks, I have tested your patch but qxl seems to have the same problem 
(qemu crash on domU xorg start).
I not see the MMIO error on logs, what must I do to see it or any 
similar debug information?
Tell me if I must do other specific test or you need other details.
Thanks for any reply.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-18 12:29 ` Fabio Fantoni
@ 2013-09-18 12:42   ` Jan Beulich
  2013-09-18 14:12     ` Fabio Fantoni
  0 siblings, 1 reply; 31+ messages in thread
From: Jan Beulich @ 2013-09-18 12:42 UTC (permalink / raw)
  To: Fabio Fantoni; +Cc: George Dunlap, Andrew Cooper, Keir Fraser, xen-devel

>>> On 18.09.13 at 14:29, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
> Il 18/09/2013 10:07, Jan Beulich ha scritto:
>>>>> On 16.09.13 at 16:10, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>> Il 05/07/2013 18:59, George Dunlap ha scritto:
>>>> On Wed, May 29, 2013 at 11:25 PM, Andrew Cooper
>>>> <andrew.cooper3@citrix.com> 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" <Ian.Jackson@eu.citrix.com> 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 <ian.jackson@eu.citrix.com>
>>>>>>> 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?
>>> Is there someone that can add full support for SSE on hvm domUs?
>>> Thanks for any reply.
>> Mind giving the attached patch a try?
> 
> Thanks, I have tested your patch but qxl seems to have the same problem 
> (qemu crash on domU xorg start).
> I not see the MMIO error on logs, what must I do to see it or any 
> similar debug information?
> Tell me if I must do other specific test or you need other details.

Without the patch you ought to have seen "bad mmio size ..."
warning in the hypervisor log. Those should be gone with the
patch I handed you. If you didn't see such warnings, then your
problem wasn't with the emulation of SSE instructions in the first
place.

As to qemu crashing - I'll have to defer to those knowing qemu
much better than I do. I merely wanted to provide the hypervisor
side change that I deemed necessary based on the information I
had (and I think that change ought to go in anyway, regardless
of whether it helps in your specific case).

Jan

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-18 12:42   ` Jan Beulich
@ 2013-09-18 14:12     ` Fabio Fantoni
  2013-09-18 14:30       ` Jan Beulich
  0 siblings, 1 reply; 31+ messages in thread
From: Fabio Fantoni @ 2013-09-18 14:12 UTC (permalink / raw)
  To: Jan Beulich; +Cc: George Dunlap, Andrew Cooper, Keir Fraser, xen-devel

Il 18/09/2013 14:42, Jan Beulich ha scritto:
>>>> On 18.09.13 at 14:29, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>> Il 18/09/2013 10:07, Jan Beulich ha scritto:
>>>>>> On 16.09.13 at 16:10, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>>> Il 05/07/2013 18:59, George Dunlap ha scritto:
>>>>> On Wed, May 29, 2013 at 11:25 PM, Andrew Cooper
>>>>> <andrew.cooper3@citrix.com> 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" <Ian.Jackson@eu.citrix.com> 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 <ian.jackson@eu.citrix.com>
>>>>>>>> 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?
>>>> Is there someone that can add full support for SSE on hvm domUs?
>>>> Thanks for any reply.
>>> Mind giving the attached patch a try?
>> Thanks, I have tested your patch but qxl seems to have the same problem
>> (qemu crash on domU xorg start).
>> I not see the MMIO error on logs, what must I do to see it or any
>> similar debug information?
>> Tell me if I must do other specific test or you need other details.
> Without the patch you ought to have seen "bad mmio size ..."

I was unable to see the MMIO error on each log files also before the patch.
I don't know if I have enable sufficent debug to log them.
And I have no ideaon how to do it.
Is there another method to test effettive working of SSE >=2 istructions?
Thanks for any reply.

> warning in the hypervisor log. Those should be gone with the
> patch I handed you. If you didn't see such warnings, then your
> problem wasn't with the emulation of SSE instructions in the first
> place.
> As to qemu crashing - I'll have to defer to those knowing qemu
> much better than I do. I merely wanted to provide the hypervisor
> side change that I deemed necessary based on the information I
> had (and I think that change ought to go in anyway, regardless
> of whether it helps in your specific case).
>
> Jan
>

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-18 14:12     ` Fabio Fantoni
@ 2013-09-18 14:30       ` Jan Beulich
  2013-09-18 15:26         ` Fabio Fantoni
  2013-09-18 15:26         ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
  0 siblings, 2 replies; 31+ messages in thread
From: Jan Beulich @ 2013-09-18 14:30 UTC (permalink / raw)
  To: Fabio Fantoni; +Cc: George Dunlap, Andrew Cooper, Keir Fraser, xen-devel

>>> On 18.09.13 at 16:12, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
> Il 18/09/2013 14:42, Jan Beulich ha scritto:
>>>>> On 18.09.13 at 14:29, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>> I not see the MMIO error on logs, what must I do to see it or any
>>> similar debug information?
>>> Tell me if I must do other specific test or you need other details.
>> Without the patch you ought to have seen "bad mmio size ..."
> 
> I was unable to see the MMIO error on each log files also before the patch.
> I don't know if I have enable sufficent debug to log them.
> And I have no ideaon how to do it.

This is a guest warning (from log level perspective), so by default
would be visible in a rate limited fashion. If you want to be certain,
just add "loglvl=all guest_loglvl=all". But I'm more and more
convinced that the information we got from you originally was
misleading.

> Is there another method to test effettive working of SSE >=2 istructions?

You realize that we're not talking about arbitrary SSE instructions,
but only such with their memory operand being in MMIO space.
Anything else doesn't hit the emulator.

Jan

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-18 14:30       ` Jan Beulich
  2013-09-18 15:26         ` Fabio Fantoni
@ 2013-09-18 15:26         ` Fabio Fantoni
  2013-09-18 15:35           ` Jan Beulich
  2013-09-18 15:35           ` [Qemu-devel] [Xen-devel] " Jan Beulich
  1 sibling, 2 replies; 31+ messages in thread
From: Fabio Fantoni @ 2013-09-18 15:26 UTC (permalink / raw)
  To: Jan Beulich
  Cc: George Dunlap, Andrew Cooper, qemu-devel, Keir Fraser,
	Anthony PERARD, xen-devel

Il 18/09/2013 16:30, Jan Beulich ha scritto:
>>>> On 18.09.13 at 16:12, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>> Il 18/09/2013 14:42, Jan Beulich ha scritto:
>>>>>> On 18.09.13 at 14:29, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>>> I not see the MMIO error on logs, what must I do to see it or any
>>>> similar debug information?
>>>> Tell me if I must do other specific test or you need other details.
>>> Without the patch you ought to have seen "bad mmio size ..."
>> I was unable to see the MMIO error on each log files also before the patch.
>> I don't know if I have enable sufficent debug to log them.
>> And I have no ideaon how to do it.
> This is a guest warning (from log level perspective), so by default
> would be visible in a rate limited fashion. If you want to be certain,
> just add "loglvl=all guest_loglvl=all". But I'm more and more
> convinced that the information we got from you originally was
> misleading.

On grub.cfg now I have:
...
multiboot       /boot/xen.gz placeholder dom0_mem=4G,max:4G loglvl=all 
guest_loglvl=all
...
But I'm unable to see debug related information in log files.
This was the test of Anthony Perard with all details about the problem:
http://lists.xen.org/archives/html/xen-devel/2013-05/msg02050.html

So my questions are:
- Is your patch aimed to completely solve cpus instrictions with MMIO 
operands > 8 byte or
- does it need also some qemu changes?
I also added qemu-devel and anthony perard on cc.
Thanks for any reply.


>
>> Is there another method to test effettive working of SSE >=2 istructions?
> You realize that we're not talking about arbitrary SSE instructions,
> but only such with their memory operand being in MMIO space.
> Anything else doesn't hit the emulator.
> Jan
>

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-18 14:30       ` Jan Beulich
@ 2013-09-18 15:26         ` Fabio Fantoni
  2013-09-18 15:26         ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
  1 sibling, 0 replies; 31+ messages in thread
From: Fabio Fantoni @ 2013-09-18 15:26 UTC (permalink / raw)
  To: Jan Beulich
  Cc: George Dunlap, Andrew Cooper, qemu-devel, Keir Fraser,
	Anthony PERARD, xen-devel

Il 18/09/2013 16:30, Jan Beulich ha scritto:
>>>> On 18.09.13 at 16:12, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>> Il 18/09/2013 14:42, Jan Beulich ha scritto:
>>>>>> On 18.09.13 at 14:29, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>>> I not see the MMIO error on logs, what must I do to see it or any
>>>> similar debug information?
>>>> Tell me if I must do other specific test or you need other details.
>>> Without the patch you ought to have seen "bad mmio size ..."
>> I was unable to see the MMIO error on each log files also before the patch.
>> I don't know if I have enable sufficent debug to log them.
>> And I have no ideaon how to do it.
> This is a guest warning (from log level perspective), so by default
> would be visible in a rate limited fashion. If you want to be certain,
> just add "loglvl=all guest_loglvl=all". But I'm more and more
> convinced that the information we got from you originally was
> misleading.

On grub.cfg now I have:
...
multiboot       /boot/xen.gz placeholder dom0_mem=4G,max:4G loglvl=all 
guest_loglvl=all
...
But I'm unable to see debug related information in log files.
This was the test of Anthony Perard with all details about the problem:
http://lists.xen.org/archives/html/xen-devel/2013-05/msg02050.html

So my questions are:
- Is your patch aimed to completely solve cpus instrictions with MMIO 
operands > 8 byte or
- does it need also some qemu changes?
I also added qemu-devel and anthony perard on cc.
Thanks for any reply.


>
>> Is there another method to test effettive working of SSE >=2 istructions?
> You realize that we're not talking about arbitrary SSE instructions,
> but only such with their memory operand being in MMIO space.
> Anything else doesn't hit the emulator.
> Jan
>

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-18 15:26         ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
  2013-09-18 15:35           ` Jan Beulich
@ 2013-09-18 15:35           ` Jan Beulich
  2013-09-19  9:22             ` Fabio Fantoni
  2013-09-19  9:22             ` Fabio Fantoni
  1 sibling, 2 replies; 31+ messages in thread
From: Jan Beulich @ 2013-09-18 15:35 UTC (permalink / raw)
  To: Fabio Fantoni
  Cc: George Dunlap, Andrew Cooper, qemu-devel, Keir Fraser,
	Anthony PERARD, xen-devel

>>> On 18.09.13 at 17:26, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
> Il 18/09/2013 16:30, Jan Beulich ha scritto:
>>>>> On 18.09.13 at 16:12, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>> Il 18/09/2013 14:42, Jan Beulich ha scritto:
>>>>>>> On 18.09.13 at 14:29, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>>>> I not see the MMIO error on logs, what must I do to see it or any
>>>>> similar debug information?
>>>>> Tell me if I must do other specific test or you need other details.
>>>> Without the patch you ought to have seen "bad mmio size ..."
>>> I was unable to see the MMIO error on each log files also before the patch.
>>> I don't know if I have enable sufficent debug to log them.
>>> And I have no ideaon how to do it.
>> This is a guest warning (from log level perspective), so by default
>> would be visible in a rate limited fashion. If you want to be certain,
>> just add "loglvl=all guest_loglvl=all". But I'm more and more
>> convinced that the information we got from you originally was
>> misleading.
> 
> On grub.cfg now I have:
> ...
> multiboot       /boot/xen.gz placeholder dom0_mem=4G,max:4G loglvl=all 
> guest_loglvl=all
> ...
> But I'm unable to see debug related information in log files.

Log files? There can be a pertinent log file only if you have some
daemon running transferring the hypervisor log into a log file.
Otherwise you need to look at "xl dmesg" output.

> This was the test of Anthony Perard with all details about the problem:
> http://lists.xen.org/archives/html/xen-devel/2013-05/msg02050.html 

See the "bad mmio size 16" and "MMIO emulation failed @ ..."
messages there?

> So my questions are:
> - Is your patch aimed to completely solve cpus instrictions with MMIO 
> operands > 8 byte or
> - does it need also some qemu changes?

The patch is aiming at completely solving the in-hypervisor
emulation issues with operands of more than 8 bytes in size.

Whether on top of that a qemu change is also necessary I
don't know, but I wouldn't have expected so.

Jan

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-18 15:26         ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
@ 2013-09-18 15:35           ` Jan Beulich
  2013-09-18 15:35           ` [Qemu-devel] [Xen-devel] " Jan Beulich
  1 sibling, 0 replies; 31+ messages in thread
From: Jan Beulich @ 2013-09-18 15:35 UTC (permalink / raw)
  To: Fabio Fantoni
  Cc: George Dunlap, Andrew Cooper, qemu-devel, Keir Fraser,
	Anthony PERARD, xen-devel

>>> On 18.09.13 at 17:26, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
> Il 18/09/2013 16:30, Jan Beulich ha scritto:
>>>>> On 18.09.13 at 16:12, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>> Il 18/09/2013 14:42, Jan Beulich ha scritto:
>>>>>>> On 18.09.13 at 14:29, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>>>> I not see the MMIO error on logs, what must I do to see it or any
>>>>> similar debug information?
>>>>> Tell me if I must do other specific test or you need other details.
>>>> Without the patch you ought to have seen "bad mmio size ..."
>>> I was unable to see the MMIO error on each log files also before the patch.
>>> I don't know if I have enable sufficent debug to log them.
>>> And I have no ideaon how to do it.
>> This is a guest warning (from log level perspective), so by default
>> would be visible in a rate limited fashion. If you want to be certain,
>> just add "loglvl=all guest_loglvl=all". But I'm more and more
>> convinced that the information we got from you originally was
>> misleading.
> 
> On grub.cfg now I have:
> ...
> multiboot       /boot/xen.gz placeholder dom0_mem=4G,max:4G loglvl=all 
> guest_loglvl=all
> ...
> But I'm unable to see debug related information in log files.

Log files? There can be a pertinent log file only if you have some
daemon running transferring the hypervisor log into a log file.
Otherwise you need to look at "xl dmesg" output.

> This was the test of Anthony Perard with all details about the problem:
> http://lists.xen.org/archives/html/xen-devel/2013-05/msg02050.html 

See the "bad mmio size 16" and "MMIO emulation failed @ ..."
messages there?

> So my questions are:
> - Is your patch aimed to completely solve cpus instrictions with MMIO 
> operands > 8 byte or
> - does it need also some qemu changes?

The patch is aiming at completely solving the in-hypervisor
emulation issues with operands of more than 8 bytes in size.

Whether on top of that a qemu change is also necessary I
don't know, but I wouldn't have expected so.

Jan

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-18 15:35           ` [Qemu-devel] [Xen-devel] " Jan Beulich
@ 2013-09-19  9:22             ` Fabio Fantoni
  2013-09-19 10:01               ` Jan Beulich
  2013-09-19 10:01               ` Jan Beulich
  2013-09-19  9:22             ` Fabio Fantoni
  1 sibling, 2 replies; 31+ messages in thread
From: Fabio Fantoni @ 2013-09-19  9:22 UTC (permalink / raw)
  To: Jan Beulich
  Cc: George Dunlap, Andrew Cooper, qemu-devel, Keir Fraser,
	Anthony PERARD, xen-devel

[-- Attachment #1: Type: text/plain, Size: 7472 bytes --]

Il 18/09/2013 17:35, Jan Beulich ha scritto:
>>>> On 18.09.13 at 17:26, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>> Il 18/09/2013 16:30, Jan Beulich ha scritto:
>>>>>> On 18.09.13 at 16:12, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>>> Il 18/09/2013 14:42, Jan Beulich ha scritto:
>>>>>>>> On 18.09.13 at 14:29, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>>>>> I not see the MMIO error on logs, what must I do to see it or any
>>>>>> similar debug information?
>>>>>> Tell me if I must do other specific test or you need other details.
>>>>> Without the patch you ought to have seen "bad mmio size ..."
>>>> I was unable to see the MMIO error on each log files also before the patch.
>>>> I don't know if I have enable sufficent debug to log them.
>>>> And I have no ideaon how to do it.
>>> This is a guest warning (from log level perspective), so by default
>>> would be visible in a rate limited fashion. If you want to be certain,
>>> just add "loglvl=all guest_loglvl=all". But I'm more and more
>>> convinced that the information we got from you originally was
>>> misleading.
>> On grub.cfg now I have:
>> ...
>> multiboot       /boot/xen.gz placeholder dom0_mem=4G,max:4G loglvl=all
>> guest_loglvl=all
>> ...
>> But I'm unable to see debug related information in log files.
> Log files? There can be a pertinent log file only if you have some
> daemon running transferring the hypervisor log into a log file.
> Otherwise you need to look at "xl dmesg" output.

Thanks for reply.
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
> (d3) Detected Xen v4.4-unstable
> (d3) Xenbus rings @0xfeffc000, event channel 4
> (d3) System requested SeaBIOS
> (d3) CPU speed is 2661 MHz
> (d3) Relocating guest memory for lowmem MMIO space disabled
> (XEN) irq.c:270: Dom3 PCI link 0 changed 0 -> 5
> (d3) PCI-ISA link 0 routed to IRQ5
> (XEN) irq.c:270: Dom3 PCI link 1 changed 0 -> 10
> (d3) PCI-ISA link 1 routed to IRQ10
> (XEN) irq.c:270: Dom3 PCI link 2 changed 0 -> 11
> (d3) PCI-ISA link 2 routed to IRQ11
> (XEN) irq.c:270: Dom3 PCI link 3 changed 0 -> 5
> (d3) PCI-ISA link 3 routed to IRQ5
> (d3) pci dev 01:3 INTA->IRQ10
> (d3) pci dev 02:0 INTA->IRQ11
> (d3) pci dev 03:0 INTA->IRQ5
> (d3) pci dev 04:0 INTA->IRQ5
> (d3) No RAM in high memory; setting high_mem resource base to 100000000
> (d3) pci dev 02:0 bar 10 size 004000000: 0f0000000
> (d3) pci dev 02:0 bar 14 size 004000000: 0f4000000
> (d3) pci dev 03:0 bar 14 size 001000000: 0f8000008
> (d3) pci dev 04:0 bar 30 size 000040000: 0f9000000
> (d3) pci dev 02:0 bar 30 size 000010000: 0f9040000
> (d3) pci dev 02:0 bar 18 size 000002000: 0f9050000
> (d3) pci dev 03:0 bar 10 size 000000100: 00000c001
> (d3) pci dev 04:0 bar 10 size 000000100: 00000c101
> (d3) pci dev 04:0 bar 14 size 000000100: 0f9052000
> (d3) pci dev 02:0 bar 1c size 000000020: 00000c201
> (d3) pci dev 01:1 bar 20 size 000000010: 00000c221
> (d3) Multiprocessor initialisation:
> (d3)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (d3)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (d3) Testing HVM environment:
> (d3)  - REP INSB across page boundaries ... passed
> (d3)  - GS base MSRs and SWAPGS ... passed
> (d3) Passed 2 of 2 tests
> (d3) Writing SMBIOS tables ...
> (d3) Loading SeaBIOS ...
> (d3) Creating MP tables ...
> (d3) Loading ACPI ...
> (d3) vm86 TSS at fc00a080
> (d3) BIOS map:
> (d3)  10000-100d3: Scratch space
> (d3)  e0000-fffff: Main BIOS
> (d3) E820 table:
> (d3)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
> (d3)  HOLE: 00000000:000a0000 - 00000000:000e0000
> (d3)  [01]: 00000000:000e0000 - 00000000:00100000: RESERVED
> (d3)  [02]: 00000000:00100000 - 00000000:78000000: RAM
> (d3)  HOLE: 00000000:78000000 - 00000000:fc000000
> (d3)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
> (d3) Invoking SeaBIOS ...
> (d3) SeaBIOS (version 
> debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-vfarm)
> (d3)
> (d3) Found Xen hypervisor signature at 40000000
> (d3) xen: copy e820...
> (d3) Relocating init from 0x000e2001 to 0x77fe0600 (size 63795)
> (d3) CPU Mhz=2662
> (d3) Found 7 PCI devices (max PCI bus is 00)
> (d3) Allocated Xen hypercall page at 77fff000
> (d3) Detected Xen v4.4-unstable
> (d3) xen: copy BIOS tables...
> (d3) Copying SMBIOS entry point from 0x00010010 to 0x000f1920
> (d3) Copying MPTABLE from 0xfc001170/fc001180 to 0x000f1820
> (d3) Copying PIR from 0x00010030 to 0x000f17a0
> (d3) Copying ACPI RSDP from 0x000100b0 to 0x000f1770
> (d3) Using pmtimer, ioport 0xb008, freq 3579 kHz
> (d3) Scan for VGA option rom
> *(d3) WARNING! Found unaligned PCI rom (vd=1b36:0100)* ***
> (d3) Running option rom at c000:0003
> *(XEN) stdvga.c:147:d3 entering stdvga and caching modes* ***
> (d3) Turning on vga text mode console
> (d3) SeaBIOS (version 
> debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-vfarm)
> (d3) Machine UUID c0d117cd-4e25-47c9-b6cb-2fa70dfd551c
> (d3) Found 1 lpt ports
> (d3) Found 1 serial ports
> (d3) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> (d3) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> (d3) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (12000 MiBytes)
> (d3) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> (d3) DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
> (d3) Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
> (d3) PS2 keyboard initialized
> (d3) All threads complete.
> (d3) Scan for option roms
> (d3) Running option rom at ca00:0003
> (d3) pmm call arg1=1
> (d3) pmm call arg1=0
> (d3) pmm call arg1=1
> (d3) pmm call arg1=0
> (d3) Searching bootorder for: /pci@i0cf8/*@4
> (d3)
> (d3) Press F12 for boot menu.
> (d3)
> (d3) Searching bootorder for: HALT
> (d3) drive 0x000f1720: PCHS=16383/16/63 translation=lba 
> LCHS=1024/255/63 s=24576000
> (d3) Space available for UMB: cb000-ee800, f0000-f16c0
> (d3) Returned 61440 bytes of ZoneHigh
> (d3) e820 map has 6 items:
> (d3)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
> (d3)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
> (d3)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
> (d3)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
> (d3)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
> (d3)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
> (d3) enter handle_19:
> (d3)   NULL
> (d3) Booting from Hard Disk...
> (d3) Booting from 0000:7c00
> (XEN) hvm.c:1213:d3 All CPUs offline -- powering off.

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).
Thanks for any reply.


>
>> This was the test of Anthony Perard with all details about the problem:
>> http://lists.xen.org/archives/html/xen-devel/2013-05/msg02050.html
> See the "bad mmio size 16" and "MMIO emulation failed @ ..."
> messages there?
>
>> So my questions are:
>> - Is your patch aimed to completely solve cpus instrictions with MMIO
>> operands > 8 byte or
>> - does it need also some qemu changes?
> The patch is aiming at completely solving the in-hypervisor
> emulation issues with operands of more than 8 bytes in size.
>
> Whether on top of that a qemu change is also necessary I
> don't know, but I wouldn't have expected so.

Someone qemu maintainer on this?
Thanks for any reply.

>
> Jan
>


[-- Attachment #2: Type: text/html, Size: 10790 bytes --]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-18 15:35           ` [Qemu-devel] [Xen-devel] " Jan Beulich
  2013-09-19  9:22             ` Fabio Fantoni
@ 2013-09-19  9:22             ` Fabio Fantoni
  1 sibling, 0 replies; 31+ messages in thread
From: Fabio Fantoni @ 2013-09-19  9:22 UTC (permalink / raw)
  To: Jan Beulich
  Cc: George Dunlap, Andrew Cooper, qemu-devel, Keir Fraser,
	Anthony PERARD, xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 7472 bytes --]

Il 18/09/2013 17:35, Jan Beulich ha scritto:
>>>> On 18.09.13 at 17:26, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>> Il 18/09/2013 16:30, Jan Beulich ha scritto:
>>>>>> On 18.09.13 at 16:12, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>>> Il 18/09/2013 14:42, Jan Beulich ha scritto:
>>>>>>>> On 18.09.13 at 14:29, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>>>>>> I not see the MMIO error on logs, what must I do to see it or any
>>>>>> similar debug information?
>>>>>> Tell me if I must do other specific test or you need other details.
>>>>> Without the patch you ought to have seen "bad mmio size ..."
>>>> I was unable to see the MMIO error on each log files also before the patch.
>>>> I don't know if I have enable sufficent debug to log them.
>>>> And I have no ideaon how to do it.
>>> This is a guest warning (from log level perspective), so by default
>>> would be visible in a rate limited fashion. If you want to be certain,
>>> just add "loglvl=all guest_loglvl=all". But I'm more and more
>>> convinced that the information we got from you originally was
>>> misleading.
>> On grub.cfg now I have:
>> ...
>> multiboot       /boot/xen.gz placeholder dom0_mem=4G,max:4G loglvl=all
>> guest_loglvl=all
>> ...
>> But I'm unable to see debug related information in log files.
> Log files? There can be a pertinent log file only if you have some
> daemon running transferring the hypervisor log into a log file.
> Otherwise you need to look at "xl dmesg" output.

Thanks for reply.
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
> (d3) Detected Xen v4.4-unstable
> (d3) Xenbus rings @0xfeffc000, event channel 4
> (d3) System requested SeaBIOS
> (d3) CPU speed is 2661 MHz
> (d3) Relocating guest memory for lowmem MMIO space disabled
> (XEN) irq.c:270: Dom3 PCI link 0 changed 0 -> 5
> (d3) PCI-ISA link 0 routed to IRQ5
> (XEN) irq.c:270: Dom3 PCI link 1 changed 0 -> 10
> (d3) PCI-ISA link 1 routed to IRQ10
> (XEN) irq.c:270: Dom3 PCI link 2 changed 0 -> 11
> (d3) PCI-ISA link 2 routed to IRQ11
> (XEN) irq.c:270: Dom3 PCI link 3 changed 0 -> 5
> (d3) PCI-ISA link 3 routed to IRQ5
> (d3) pci dev 01:3 INTA->IRQ10
> (d3) pci dev 02:0 INTA->IRQ11
> (d3) pci dev 03:0 INTA->IRQ5
> (d3) pci dev 04:0 INTA->IRQ5
> (d3) No RAM in high memory; setting high_mem resource base to 100000000
> (d3) pci dev 02:0 bar 10 size 004000000: 0f0000000
> (d3) pci dev 02:0 bar 14 size 004000000: 0f4000000
> (d3) pci dev 03:0 bar 14 size 001000000: 0f8000008
> (d3) pci dev 04:0 bar 30 size 000040000: 0f9000000
> (d3) pci dev 02:0 bar 30 size 000010000: 0f9040000
> (d3) pci dev 02:0 bar 18 size 000002000: 0f9050000
> (d3) pci dev 03:0 bar 10 size 000000100: 00000c001
> (d3) pci dev 04:0 bar 10 size 000000100: 00000c101
> (d3) pci dev 04:0 bar 14 size 000000100: 0f9052000
> (d3) pci dev 02:0 bar 1c size 000000020: 00000c201
> (d3) pci dev 01:1 bar 20 size 000000010: 00000c221
> (d3) Multiprocessor initialisation:
> (d3)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (d3)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
> (d3) Testing HVM environment:
> (d3)  - REP INSB across page boundaries ... passed
> (d3)  - GS base MSRs and SWAPGS ... passed
> (d3) Passed 2 of 2 tests
> (d3) Writing SMBIOS tables ...
> (d3) Loading SeaBIOS ...
> (d3) Creating MP tables ...
> (d3) Loading ACPI ...
> (d3) vm86 TSS at fc00a080
> (d3) BIOS map:
> (d3)  10000-100d3: Scratch space
> (d3)  e0000-fffff: Main BIOS
> (d3) E820 table:
> (d3)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
> (d3)  HOLE: 00000000:000a0000 - 00000000:000e0000
> (d3)  [01]: 00000000:000e0000 - 00000000:00100000: RESERVED
> (d3)  [02]: 00000000:00100000 - 00000000:78000000: RAM
> (d3)  HOLE: 00000000:78000000 - 00000000:fc000000
> (d3)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
> (d3) Invoking SeaBIOS ...
> (d3) SeaBIOS (version 
> debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-vfarm)
> (d3)
> (d3) Found Xen hypervisor signature at 40000000
> (d3) xen: copy e820...
> (d3) Relocating init from 0x000e2001 to 0x77fe0600 (size 63795)
> (d3) CPU Mhz=2662
> (d3) Found 7 PCI devices (max PCI bus is 00)
> (d3) Allocated Xen hypercall page at 77fff000
> (d3) Detected Xen v4.4-unstable
> (d3) xen: copy BIOS tables...
> (d3) Copying SMBIOS entry point from 0x00010010 to 0x000f1920
> (d3) Copying MPTABLE from 0xfc001170/fc001180 to 0x000f1820
> (d3) Copying PIR from 0x00010030 to 0x000f17a0
> (d3) Copying ACPI RSDP from 0x000100b0 to 0x000f1770
> (d3) Using pmtimer, ioport 0xb008, freq 3579 kHz
> (d3) Scan for VGA option rom
> *(d3) WARNING! Found unaligned PCI rom (vd=1b36:0100)* ***
> (d3) Running option rom at c000:0003
> *(XEN) stdvga.c:147:d3 entering stdvga and caching modes* ***
> (d3) Turning on vga text mode console
> (d3) SeaBIOS (version 
> debian/1.7.3-1-1-ga76c6f1-dirty-20130813_122010-vfarm)
> (d3) Machine UUID c0d117cd-4e25-47c9-b6cb-2fa70dfd551c
> (d3) Found 1 lpt ports
> (d3) Found 1 serial ports
> (d3) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
> (d3) ATA controller 2 at 170/374/0 (irq 15 dev 9)
> (d3) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (12000 MiBytes)
> (d3) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
> (d3) DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
> (d3) Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0
> (d3) PS2 keyboard initialized
> (d3) All threads complete.
> (d3) Scan for option roms
> (d3) Running option rom at ca00:0003
> (d3) pmm call arg1=1
> (d3) pmm call arg1=0
> (d3) pmm call arg1=1
> (d3) pmm call arg1=0
> (d3) Searching bootorder for: /pci@i0cf8/*@4
> (d3)
> (d3) Press F12 for boot menu.
> (d3)
> (d3) Searching bootorder for: HALT
> (d3) drive 0x000f1720: PCHS=16383/16/63 translation=lba 
> LCHS=1024/255/63 s=24576000
> (d3) Space available for UMB: cb000-ee800, f0000-f16c0
> (d3) Returned 61440 bytes of ZoneHigh
> (d3) e820 map has 6 items:
> (d3)   0: 0000000000000000 - 000000000009fc00 = 1 RAM
> (d3)   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
> (d3)   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
> (d3)   3: 0000000000100000 - 0000000077fff000 = 1 RAM
> (d3)   4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
> (d3)   5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
> (d3) enter handle_19:
> (d3)   NULL
> (d3) Booting from Hard Disk...
> (d3) Booting from 0000:7c00
> (XEN) hvm.c:1213:d3 All CPUs offline -- powering off.

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).
Thanks for any reply.


>
>> This was the test of Anthony Perard with all details about the problem:
>> http://lists.xen.org/archives/html/xen-devel/2013-05/msg02050.html
> See the "bad mmio size 16" and "MMIO emulation failed @ ..."
> messages there?
>
>> So my questions are:
>> - Is your patch aimed to completely solve cpus instrictions with MMIO
>> operands > 8 byte or
>> - does it need also some qemu changes?
> The patch is aiming at completely solving the in-hypervisor
> emulation issues with operands of more than 8 bytes in size.
>
> Whether on top of that a qemu change is also necessary I
> don't know, but I wouldn't have expected so.

Someone qemu maintainer on this?
Thanks for any reply.

>
> Jan
>


[-- Attachment #1.2: Type: text/html, Size: 10790 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-19  9:22             ` Fabio Fantoni
@ 2013-09-19 10:01               ` Jan Beulich
  2013-09-19 10:04                 ` George Dunlap
  2013-09-19 10:04                 ` [Qemu-devel] [Xen-devel] " George Dunlap
  2013-09-19 10:01               ` Jan Beulich
  1 sibling, 2 replies; 31+ messages in thread
From: Jan Beulich @ 2013-09-19 10:01 UTC (permalink / raw)
  To: Fabio Fantoni
  Cc: George Dunlap, Andrew Cooper, qemu-devel, Keir Fraser,
	Anthony PERARD, xen-devel

>>> On 19.09.13 at 11:22, Fabio Fantoni <fabio.fantoni@m2r.biz> 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.

Jan

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-19  9:22             ` Fabio Fantoni
  2013-09-19 10:01               ` Jan Beulich
@ 2013-09-19 10:01               ` Jan Beulich
  1 sibling, 0 replies; 31+ messages in thread
From: Jan Beulich @ 2013-09-19 10:01 UTC (permalink / raw)
  To: Fabio Fantoni
  Cc: George Dunlap, Andrew Cooper, qemu-devel, Keir Fraser,
	Anthony PERARD, xen-devel

>>> On 19.09.13 at 11:22, Fabio Fantoni <fabio.fantoni@m2r.biz> 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.

Jan

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-19 10:01               ` Jan Beulich
  2013-09-19 10:04                 ` George Dunlap
@ 2013-09-19 10:04                 ` George Dunlap
  2013-09-19 11:08                   ` Fabio Fantoni
  2013-09-19 11:08                   ` Fabio Fantoni
  1 sibling, 2 replies; 31+ messages in thread
From: George Dunlap @ 2013-09-19 10:04 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Keir Fraser, Andrew Cooper, qemu-devel, Fabio Fantoni,
	Anthony PERARD, xen-devel

On 19/09/13 11:01, Jan Beulich wrote:
>>>> On 19.09.13 at 11:22, Fabio Fantoni <fabio.fantoni@m2r.biz> 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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-19 10:01               ` Jan Beulich
@ 2013-09-19 10:04                 ` George Dunlap
  2013-09-19 10:04                 ` [Qemu-devel] [Xen-devel] " George Dunlap
  1 sibling, 0 replies; 31+ messages in thread
From: George Dunlap @ 2013-09-19 10:04 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Keir Fraser, Andrew Cooper, qemu-devel, Fabio Fantoni,
	Anthony PERARD, xen-devel

On 19/09/13 11:01, Jan Beulich wrote:
>>>> On 19.09.13 at 11:22, Fabio Fantoni <fabio.fantoni@m2r.biz> 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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-18  8:07 [PATCH] libxl: Remove qxl support for the 4.3 release Jan Beulich
  2013-09-18 12:29 ` Fabio Fantoni
@ 2013-09-19 10:09 ` George Dunlap
  2013-09-19 10:15   ` Processed: " xen
  1 sibling, 1 reply; 31+ messages in thread
From: George Dunlap @ 2013-09-19 10:09 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, Fabio Fantoni, Keir Fraser, xen-devel

graft 11 ^
thanks

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Processed: Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-19 10:09 ` George Dunlap
@ 2013-09-19 10:15   ` xen
  0 siblings, 0 replies; 31+ messages in thread
From: xen @ 2013-09-19 10:15 UTC (permalink / raw)
  To: George Dunlap, xen-devel

Processing commands for xen@bugs.xenproject.org:

> graft 11 ^
Graft `<52397B4C02000078000F43F7@nat28.tlf.novell.com>' onto #11
> thanks
Finished processing.

Modified/created Bugs:
 - 11: http://bugs.xenproject.org/xen/bug/11

---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs
Contact xen-bugs-owner@bugs.xenproject.org with any infrastructure issues

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [Qemu-devel] [Xen-devel] [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-19 10:04                 ` [Qemu-devel] [Xen-devel] " George Dunlap
@ 2013-09-19 11:08                   ` Fabio Fantoni
  2013-09-19 11:08                   ` Fabio Fantoni
  1 sibling, 0 replies; 31+ messages in thread
From: Fabio Fantoni @ 2013-09-19 11:08 UTC (permalink / raw)
  To: George Dunlap
  Cc: Andrew Cooper, qemu-devel, 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 <fabio.fantoni@m2r.biz> 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.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-19 10:04                 ` [Qemu-devel] [Xen-devel] " George Dunlap
  2013-09-19 11:08                   ` Fabio Fantoni
@ 2013-09-19 11:08                   ` Fabio Fantoni
  1 sibling, 0 replies; 31+ messages in thread
From: Fabio Fantoni @ 2013-09-19 11:08 UTC (permalink / raw)
  To: George Dunlap
  Cc: Andrew Cooper, qemu-devel, 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 <fabio.fantoni@m2r.biz> 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.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-16 14:28             ` Jan Beulich
@ 2013-09-16 14:49               ` Fabio Fantoni
  0 siblings, 0 replies; 31+ messages in thread
From: Fabio Fantoni @ 2013-09-16 14:49 UTC (permalink / raw)
  To: Jan Beulich; +Cc: George Dunlap, Andrew Cooper, Keir Fraser, xen-devel

Il 16/09/2013 16:28, Jan Beulich ha scritto:
>>>> On 16.09.13 at 16:10, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
>> Il 05/07/2013 18:59, George Dunlap ha scritto:
>>> On Wed, May 29, 2013 at 11:25 PM, Andrew Cooper
>>> <andrew.cooper3@citrix.com> 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" <Ian.Jackson@eu.citrix.com> 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 <ian.jackson@eu.citrix.com>
>>>>>> 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?
>> Is there someone that can add full support for SSE on hvm domUs?
>> Thanks for any reply.
> I was intending to take a look whether this can be done without
> altering the interface with qemu, in which case I may be able to
> get this implemented. But as long as higher priority work keeps
> showing up, this will continue to get deferred...
>
> Jan
>

Thanks a lot for keep this on your todo list. Please keep me in touch 
soon as you eventually post any patch on this. I will greatly appreciate 
and test it.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-09-16 14:10           ` Fabio Fantoni
@ 2013-09-16 14:28             ` Jan Beulich
  2013-09-16 14:49               ` Fabio Fantoni
  0 siblings, 1 reply; 31+ messages in thread
From: Jan Beulich @ 2013-09-16 14:28 UTC (permalink / raw)
  To: George Dunlap, Fabio Fantoni; +Cc: Andrew Cooper, Keir Fraser, xen-devel

>>> On 16.09.13 at 16:10, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote:
> Il 05/07/2013 18:59, George Dunlap ha scritto:
>> On Wed, May 29, 2013 at 11:25 PM, Andrew Cooper
>> <andrew.cooper3@citrix.com> 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" <Ian.Jackson@eu.citrix.com> 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 <ian.jackson@eu.citrix.com>
>>>>> 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?
> 
> Is there someone that can add full support for SSE on hvm domUs?
> Thanks for any reply.

I was intending to take a look whether this can be done without
altering the interface with qemu, in which case I may be able to
get this implemented. But as long as higher priority work keeps
showing up, this will continue to get deferred...

Jan

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-07-05 16:59         ` George Dunlap
@ 2013-09-16 14:10           ` Fabio Fantoni
  2013-09-16 14:28             ` Jan Beulich
  0 siblings, 1 reply; 31+ messages in thread
From: Fabio Fantoni @ 2013-09-16 14:10 UTC (permalink / raw)
  To: George Dunlap; +Cc: Andrew Cooper, Keir Fraser, Jan Beulich, xen-devel

Il 05/07/2013 18:59, George Dunlap ha scritto:
> On Wed, May 29, 2013 at 11:25 PM, Andrew Cooper
> <andrew.cooper3@citrix.com> 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" <Ian.Jackson@eu.citrix.com> 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 <ian.jackson@eu.citrix.com>
>>>> 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

Is there someone that can add full support for SSE on hvm domUs?
Thanks for any reply.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-05-29 22:25       ` Andrew Cooper
@ 2013-07-05 16:59         ` George Dunlap
  2013-09-16 14:10           ` Fabio Fantoni
  0 siblings, 1 reply; 31+ messages in thread
From: George Dunlap @ 2013-07-05 16:59 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: Fabio Fantoni, Keir Fraser, Jan Beulich, xen-devel

On Wed, May 29, 2013 at 11:25 PM, Andrew Cooper
<andrew.cooper3@citrix.com> 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" <Ian.Jackson@eu.citrix.com> 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 <ian.jackson@eu.citrix.com>
>>> 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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-05-28 16:51 ` Ian Jackson
  2013-05-28 18:09   ` Keir Fraser
@ 2013-05-30  8:57   ` Ian Campbell
  1 sibling, 0 replies; 31+ messages in thread
From: Ian Campbell @ 2013-05-30  8:57 UTC (permalink / raw)
  To: Ian Jackson; +Cc: George Dunlap, Fabio Fantoni, xen-devel

On Tue, 2013-05-28 at 17:51 +0100, 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 <ian.jackson@eu.citrix.com>

Also Acked & applied, thanks.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-05-29  7:43     ` Ian Campbell
@ 2013-05-29 22:25       ` Andrew Cooper
  2013-07-05 16:59         ` George Dunlap
  0 siblings, 1 reply; 31+ messages in thread
From: Andrew Cooper @ 2013-05-29 22:25 UTC (permalink / raw)
  To: Ian Campbell
  Cc: George Dunlap, Keir Fraser, Ian Jackson, Fabio Fantoni, xen-devel

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" <Ian.Jackson@eu.citrix.com> 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 <ian.jackson@eu.citrix.com>
>> 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

>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-05-24 15:20 George Dunlap
  2013-05-28 16:51 ` Ian Jackson
@ 2013-05-29 15:01 ` George Dunlap
  1 sibling, 0 replies; 31+ messages in thread
From: George Dunlap @ 2013-05-29 15:01 UTC (permalink / raw)
  To: xen-devel, xenbugs
  Cc: George Dunlap, Ian Jackson, Fabio Fantoni, Ian Campbell

create ^
title -1 qxl hypervisor support
thanks

On Fri, May 24, 2013 at 4:20 PM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> 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.
>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> CC: Ian Jackson <ian.jackson@citrix.com>
> CC: Ian Campbell <ian.campbell@citrix.com>
> CC: Fabio Fantoni <fabio.fantoni@m2r.biz>
> ---
>  docs/man/xl.cfg.pod.5       |   10 +---------
>  tools/libxl/libxl_create.c  |   16 ----------------
>  tools/libxl/libxl_dm.c      |   13 -------------
>  tools/libxl/libxl_types.idl |    1 -
>  tools/libxl/xl_cmdimpl.c    |    2 --
>  5 files changed, 1 insertion(+), 41 deletions(-)
>
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index e0c3bb2..a0c7430 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -1005,9 +1005,6 @@ the amount of video ram is fixed at 4MB which is sufficient
>  for 1024x768 at 32 bpp and videoram option is currently working
>  only when using the upstream qemu-xen device-model.
>
> -For B<qxl> vga, the default is both default and minimal 128MB.
> -If B<videoram> is set less than 128MB, an error will be triggered.
> -
>  =item B<stdvga=BOOLEAN>
>
>  Select a standard VGA card with VBE (VESA BIOS Extensions) as the
> @@ -1019,14 +1016,9 @@ This option is deprecated, use vga="stdvga" instead.
>
>  =item B<vga="STRING">
>
> -Selects the emulated video card (stdvga|cirrus|qxl).
> +Selects the emulated video card (stdvga|cirrus).
>  The default is cirrus.
>
> -In general, QXL should work with the Spice remote display protocol
> -for acceleration, and QXL driver is necessary in guest in this case.
> -QXL can also work with the VNC protocol, but it will be like a standard
> -VGA without acceleration.
> -
>  =item B<vnc=BOOLEAN>
>
>  Allow access to the display via the VNC protocol.  This enables the
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index cb9c822..0c32d0b 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -213,22 +213,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>          if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
>              b_info->shadow_memkb = 0;
>
> -        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
> -            if (b_info->device_model_version ==
> -               LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> -                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
> -                    b_info->video_memkb = (128 * 1024);
> -                } else if (b_info->video_memkb < (128 * 1024)) {
> -                    LOG(ERROR,
> -                        "128 Mib videoram is the minimum for qxl default");
> -                    return ERROR_INVAL;
> -                }
> -            } else {
> -                LOG(ERROR,"qemu upstream required for qxl vga");
> -                return ERROR_INVAL;
> -            }
> -        }
> -
>          if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_STD &&
>              b_info->device_model_version ==
>              LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index d10a58f..4e56ffa 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -191,8 +191,6 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
>              break;
>          case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
>              break;
> -        case LIBXL_VGA_INTERFACE_TYPE_QXL:
> -            break;
>          }
>
>          if (b_info->u.hvm.boot) {
> @@ -479,17 +477,6 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
>                      libxl__sizekb_to_mb(b_info->video_memkb)), NULL);
>              }
>              break;
> -        case LIBXL_VGA_INTERFACE_TYPE_QXL:
> -            /* QXL have 2 ram regions, ram and vram */
> -            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
> -            if (b_info->video_memkb) {
> -                flexarray_vappend(dm_args, "-global",
> -                    GCSPRINTF("qxl-vga.vram_size_mb=%"PRIu64,
> -                    (b_info->video_memkb/2/1024)), "-global",
> -                    GCSPRINTF("qxl-vga.ram_size_mb=%"PRIu64,
> -                    (b_info->video_memkb/2/1024)), NULL);
> -            }
> -            break;
>          }
>
>          if (b_info->u.hvm.boot) {
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 8262cba..d218a2d 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -130,7 +130,6 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
>  libxl_vga_interface_type = Enumeration("vga_interface_type", [
>      (1, "CIRRUS"),
>      (2, "STD"),
> -    (3, "QXL"),
>      ], init_val = 0)
>
>  #
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index e13a64e..148320c 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1456,8 +1456,6 @@ skip_vfb:
>                  b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;
>              } else if (!strcmp(buf, "cirrus")) {
>                  b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
> -            } else if (!strcmp(buf, "qxl")) {
> -                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_QXL;
>              } else {
>                  fprintf(stderr, "Unknown vga \"%s\" specified\n", buf);
>                  exit(1);
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-05-28 18:09   ` Keir Fraser
  2013-05-29  7:43     ` Ian Campbell
@ 2013-05-29 10:24     ` George Dunlap
  1 sibling, 0 replies; 31+ messages in thread
From: George Dunlap @ 2013-05-29 10:24 UTC (permalink / raw)
  To: Keir Fraser; +Cc: Fabio Fantoni, Ian Jackson, Ian Campbell, xen-devel

On 28/05/13 19:09, Keir Fraser wrote:
> On 28/05/2013 17:51, "Ian Jackson" <Ian.Jackson@eu.citrix.com> 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 <ian.jackson@eu.citrix.com>
> 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.

Would this require changes to qemu?

It's definitely too late in the release cycle to be making this kind of 
change, especially because, as Ian said, we don't know how many more 
niggles we may run into if we fix this one.

  -George

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-05-28 18:09   ` Keir Fraser
@ 2013-05-29  7:43     ` Ian Campbell
  2013-05-29 22:25       ` Andrew Cooper
  2013-05-29 10:24     ` George Dunlap
  1 sibling, 1 reply; 31+ messages in thread
From: Ian Campbell @ 2013-05-29  7:43 UTC (permalink / raw)
  To: Keir Fraser; +Cc: George Dunlap, Fabio Fantoni, Ian Jackson, xen-devel

On Tue, 2013-05-28 at 19:09 +0100, Keir Fraser wrote:
> On 28/05/2013 17:51, "Ian Jackson" <Ian.Jackson@eu.citrix.com> 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 <ian.jackson@eu.citrix.com>
> 
> 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.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-05-28 16:51 ` Ian Jackson
@ 2013-05-28 18:09   ` Keir Fraser
  2013-05-29  7:43     ` Ian Campbell
  2013-05-29 10:24     ` George Dunlap
  2013-05-30  8:57   ` Ian Campbell
  1 sibling, 2 replies; 31+ messages in thread
From: Keir Fraser @ 2013-05-28 18:09 UTC (permalink / raw)
  To: Ian Jackson, George Dunlap; +Cc: Fabio Fantoni, Ian Campbell, xen-devel

On 28/05/2013 17:51, "Ian Jackson" <Ian.Jackson@eu.citrix.com> 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 <ian.jackson@eu.citrix.com>

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.

 -- Keir

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] libxl: Remove qxl support for the 4.3 release
  2013-05-24 15:20 George Dunlap
@ 2013-05-28 16:51 ` Ian Jackson
  2013-05-28 18:09   ` Keir Fraser
  2013-05-30  8:57   ` Ian Campbell
  2013-05-29 15:01 ` George Dunlap
  1 sibling, 2 replies; 31+ messages in thread
From: Ian Jackson @ 2013-05-28 16:51 UTC (permalink / raw)
  To: George Dunlap; +Cc: Fabio Fantoni, Ian Campbell, xen-devel

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 <ian.jackson@eu.citrix.com>

^ permalink raw reply	[flat|nested] 31+ messages in thread

* [PATCH] libxl: Remove qxl support for the 4.3 release
@ 2013-05-24 15:20 George Dunlap
  2013-05-28 16:51 ` Ian Jackson
  2013-05-29 15:01 ` George Dunlap
  0 siblings, 2 replies; 31+ messages in thread
From: George Dunlap @ 2013-05-24 15:20 UTC (permalink / raw)
  To: xen-devel; +Cc: George Dunlap, Ian Jackson, Fabio Fantoni, Ian Campbell

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.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Fabio Fantoni <fabio.fantoni@m2r.biz>
---
 docs/man/xl.cfg.pod.5       |   10 +---------
 tools/libxl/libxl_create.c  |   16 ----------------
 tools/libxl/libxl_dm.c      |   13 -------------
 tools/libxl/libxl_types.idl |    1 -
 tools/libxl/xl_cmdimpl.c    |    2 --
 5 files changed, 1 insertion(+), 41 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index e0c3bb2..a0c7430 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1005,9 +1005,6 @@ the amount of video ram is fixed at 4MB which is sufficient
 for 1024x768 at 32 bpp and videoram option is currently working
 only when using the upstream qemu-xen device-model.
 
-For B<qxl> vga, the default is both default and minimal 128MB.
-If B<videoram> is set less than 128MB, an error will be triggered.
-
 =item B<stdvga=BOOLEAN>
 
 Select a standard VGA card with VBE (VESA BIOS Extensions) as the
@@ -1019,14 +1016,9 @@ This option is deprecated, use vga="stdvga" instead.
 
 =item B<vga="STRING">
 
-Selects the emulated video card (stdvga|cirrus|qxl).
+Selects the emulated video card (stdvga|cirrus).
 The default is cirrus.
 
-In general, QXL should work with the Spice remote display protocol
-for acceleration, and QXL driver is necessary in guest in this case.
-QXL can also work with the VNC protocol, but it will be like a standard
-VGA without acceleration.
-
 =item B<vnc=BOOLEAN>
 
 Allow access to the display via the VNC protocol.  This enables the
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index cb9c822..0c32d0b 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -213,22 +213,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
         if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
             b_info->shadow_memkb = 0;
 
-        if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_QXL) {
-            if (b_info->device_model_version ==
-               LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
-                if (b_info->video_memkb == LIBXL_MEMKB_DEFAULT) {
-                    b_info->video_memkb = (128 * 1024);
-                } else if (b_info->video_memkb < (128 * 1024)) {
-                    LOG(ERROR,
-                        "128 Mib videoram is the minimum for qxl default");
-                    return ERROR_INVAL;
-                }
-            } else {
-                LOG(ERROR,"qemu upstream required for qxl vga");
-                return ERROR_INVAL;
-            }
-        }
-
         if (b_info->u.hvm.vga.kind == LIBXL_VGA_INTERFACE_TYPE_STD &&
             b_info->device_model_version ==
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index d10a58f..4e56ffa 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -191,8 +191,6 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
             break;
         case LIBXL_VGA_INTERFACE_TYPE_CIRRUS:
             break;
-        case LIBXL_VGA_INTERFACE_TYPE_QXL:
-            break;
         }
 
         if (b_info->u.hvm.boot) {
@@ -479,17 +477,6 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                     libxl__sizekb_to_mb(b_info->video_memkb)), NULL);
             }
             break;
-        case LIBXL_VGA_INTERFACE_TYPE_QXL:
-            /* QXL have 2 ram regions, ram and vram */
-            flexarray_vappend(dm_args, "-vga", "qxl", NULL);
-            if (b_info->video_memkb) {
-                flexarray_vappend(dm_args, "-global",
-                    GCSPRINTF("qxl-vga.vram_size_mb=%"PRIu64,
-                    (b_info->video_memkb/2/1024)), "-global",
-                    GCSPRINTF("qxl-vga.ram_size_mb=%"PRIu64,
-                    (b_info->video_memkb/2/1024)), NULL);
-            }
-            break;
         }
 
         if (b_info->u.hvm.boot) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 8262cba..d218a2d 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -130,7 +130,6 @@ libxl_shutdown_reason = Enumeration("shutdown_reason", [
 libxl_vga_interface_type = Enumeration("vga_interface_type", [
     (1, "CIRRUS"),
     (2, "STD"),
-    (3, "QXL"),
     ], init_val = 0)
 
 #
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index e13a64e..148320c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1456,8 +1456,6 @@ skip_vfb:
                 b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;
             } else if (!strcmp(buf, "cirrus")) {
                 b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
-            } else if (!strcmp(buf, "qxl")) {
-                b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_QXL;
             } else {
                 fprintf(stderr, "Unknown vga \"%s\" specified\n", buf);
                 exit(1);
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2013-09-19 11:08 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-18  8:07 [PATCH] libxl: Remove qxl support for the 4.3 release Jan Beulich
2013-09-18 12:29 ` Fabio Fantoni
2013-09-18 12:42   ` Jan Beulich
2013-09-18 14:12     ` Fabio Fantoni
2013-09-18 14:30       ` Jan Beulich
2013-09-18 15:26         ` Fabio Fantoni
2013-09-18 15:26         ` [Qemu-devel] [Xen-devel] " Fabio Fantoni
2013-09-18 15:35           ` Jan Beulich
2013-09-18 15:35           ` [Qemu-devel] [Xen-devel] " Jan Beulich
2013-09-19  9:22             ` Fabio Fantoni
2013-09-19 10:01               ` Jan Beulich
2013-09-19 10:04                 ` George Dunlap
2013-09-19 10:04                 ` [Qemu-devel] [Xen-devel] " George Dunlap
2013-09-19 11:08                   ` Fabio Fantoni
2013-09-19 11:08                   ` Fabio Fantoni
2013-09-19 10:01               ` Jan Beulich
2013-09-19  9:22             ` Fabio Fantoni
2013-09-19 10:09 ` George Dunlap
2013-09-19 10:15   ` Processed: " xen
  -- strict thread matches above, loose matches on Subject: below --
2013-05-24 15:20 George Dunlap
2013-05-28 16:51 ` Ian Jackson
2013-05-28 18:09   ` Keir Fraser
2013-05-29  7:43     ` Ian Campbell
2013-05-29 22:25       ` Andrew Cooper
2013-07-05 16:59         ` George Dunlap
2013-09-16 14:10           ` Fabio Fantoni
2013-09-16 14:28             ` Jan Beulich
2013-09-16 14:49               ` Fabio Fantoni
2013-05-29 10:24     ` George Dunlap
2013-05-30  8:57   ` Ian Campbell
2013-05-29 15:01 ` George Dunlap

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.