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
Ian Jackson
2013-May-28 16:51 UTC
Re: [PATCH] libxl: Remove qxl support for the 4.3 release
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>
Keir Fraser
2013-May-28 18:09 UTC
Re: [PATCH] libxl: Remove qxl support for the 4.3 release
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
Ian Campbell
2013-May-29 07:43 UTC
Re: [PATCH] libxl: Remove qxl support for the 4.3 release
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.
George Dunlap
2013-May-29 10:24 UTC
Re: [PATCH] libxl: Remove qxl support for the 4.3 release
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
George Dunlap
2013-May-29 15:01 UTC
Re: [PATCH] libxl: Remove qxl support for the 4.3 release
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
Andrew Cooper
2013-May-29 22:25 UTC
Re: [PATCH] libxl: Remove qxl support for the 4.3 release
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
Ian Campbell
2013-May-30 08:57 UTC
Re: [PATCH] libxl: Remove qxl support for the 4.3 release
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.
George Dunlap
2013-Jul-05 16:59 UTC
Re: [PATCH] libxl: Remove qxl support for the 4.3 release
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
Fabio Fantoni
2013-Sep-16 14:10 UTC
Re: [PATCH] libxl: Remove qxl support for the 4.3 release
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? > > -GeorgeIs there someone that can add full support for SSE on hvm domUs? Thanks for any reply.
Jan Beulich
2013-Sep-16 14:28 UTC
Re: [PATCH] libxl: Remove qxl support for the 4.3 release
>>> 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
Fabio Fantoni
2013-Sep-16 14:49 UTC
Re: [PATCH] libxl: Remove qxl support for the 4.3 release
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.