* [PATCH] x86_emulate: properly do IP updates and other side effects on success
@ 2014-08-07 8:30 Jan Beulich
2014-08-07 11:40 ` Andrew Cooper
2014-08-07 13:24 ` Fabio Fantoni
0 siblings, 2 replies; 11+ messages in thread
From: Jan Beulich @ 2014-08-07 8:30 UTC (permalink / raw)
To: xen-devel; +Cc: Keir Fraser
[-- Attachment #1: Type: text/plain, Size: 3106 bytes --]
The two MMX/SSE/AVX code blocks failed to update IP properly, and these
as well as get_reg_refix(), which "manually" updated IP so far, failed
to do the TF and RF processing needed at the end of successfully
emulated instructions.
Reported-by: Andrei LUTAS <vlutas@bitdefender.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -720,29 +720,26 @@ do{ uint8_t stub[] = { _bytes, 0xc3 };
put_fpu(&fic); \
} while (0)
-static unsigned long __get_rep_prefix(
- struct cpu_user_regs *int_regs,
- struct cpu_user_regs *ext_regs,
+static unsigned long _get_rep_prefix(
+ const struct cpu_user_regs *int_regs,
int ad_bytes)
{
- unsigned long ecx = ((ad_bytes == 2) ? (uint16_t)int_regs->ecx :
- (ad_bytes == 4) ? (uint32_t)int_regs->ecx :
- int_regs->ecx);
-
- /* Skip the instruction if no repetitions are required. */
- if ( ecx == 0 )
- ext_regs->eip = int_regs->eip;
-
- return ecx;
+ return (ad_bytes == 2) ? (uint16_t)int_regs->ecx :
+ (ad_bytes == 4) ? (uint32_t)int_regs->ecx :
+ int_regs->ecx;
}
#define get_rep_prefix() ({ \
unsigned long max_reps = 1; \
if ( rep_prefix() ) \
- max_reps = __get_rep_prefix(&_regs, ctxt->regs, ad_bytes); \
+ max_reps = _get_rep_prefix(&_regs, ad_bytes); \
if ( max_reps == 0 ) \
- goto done; \
- max_reps; \
+ { \
+ /* Skip the instruction if no repetitions are required. */ \
+ dst.type = OP_NONE; \
+ goto writeback; \
+ } \
+ max_reps; \
})
static void __put_rep_prefix(
@@ -3921,7 +3918,8 @@ x86_emulate(
if ( !rc && (b & 1) && (ea.type == OP_MEM) )
rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
ea.bytes, ctxt);
- goto done;
+ dst.type = OP_NONE;
+ break;
}
case 0x20: /* mov cr,reg */
@@ -4188,7 +4186,8 @@ x86_emulate(
if ( !rc && (b != 0x6f) && (ea.type == OP_MEM) )
rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
ea.bytes, ctxt);
- goto done;
+ dst.type = OP_NONE;
+ break;
}
case 0x80 ... 0x8f: /* jcc (near) */ {
[-- Attachment #2: x86emul-IP-updates.patch --]
[-- Type: text/plain, Size: 3173 bytes --]
x86_emulate: properly do IP updates and other side effects on success
The two MMX/SSE/AVX code blocks failed to update IP properly, and these
as well as get_reg_refix(), which "manually" updated IP so far, failed
to do the TF and RF processing needed at the end of successfully
emulated instructions.
Reported-by: Andrei LUTAS <vlutas@bitdefender.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -720,29 +720,26 @@ do{ uint8_t stub[] = { _bytes, 0xc3 };
put_fpu(&fic); \
} while (0)
-static unsigned long __get_rep_prefix(
- struct cpu_user_regs *int_regs,
- struct cpu_user_regs *ext_regs,
+static unsigned long _get_rep_prefix(
+ const struct cpu_user_regs *int_regs,
int ad_bytes)
{
- unsigned long ecx = ((ad_bytes == 2) ? (uint16_t)int_regs->ecx :
- (ad_bytes == 4) ? (uint32_t)int_regs->ecx :
- int_regs->ecx);
-
- /* Skip the instruction if no repetitions are required. */
- if ( ecx == 0 )
- ext_regs->eip = int_regs->eip;
-
- return ecx;
+ return (ad_bytes == 2) ? (uint16_t)int_regs->ecx :
+ (ad_bytes == 4) ? (uint32_t)int_regs->ecx :
+ int_regs->ecx;
}
#define get_rep_prefix() ({ \
unsigned long max_reps = 1; \
if ( rep_prefix() ) \
- max_reps = __get_rep_prefix(&_regs, ctxt->regs, ad_bytes); \
+ max_reps = _get_rep_prefix(&_regs, ad_bytes); \
if ( max_reps == 0 ) \
- goto done; \
- max_reps; \
+ { \
+ /* Skip the instruction if no repetitions are required. */ \
+ dst.type = OP_NONE; \
+ goto writeback; \
+ } \
+ max_reps; \
})
static void __put_rep_prefix(
@@ -3921,7 +3918,8 @@ x86_emulate(
if ( !rc && (b & 1) && (ea.type == OP_MEM) )
rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
ea.bytes, ctxt);
- goto done;
+ dst.type = OP_NONE;
+ break;
}
case 0x20: /* mov cr,reg */
@@ -4188,7 +4186,8 @@ x86_emulate(
if ( !rc && (b != 0x6f) && (ea.type == OP_MEM) )
rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
ea.bytes, ctxt);
- goto done;
+ dst.type = OP_NONE;
+ break;
}
case 0x80 ... 0x8f: /* jcc (near) */ {
[-- 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] 11+ messages in thread
* Re: [PATCH] x86_emulate: properly do IP updates and other side effects on success
2014-08-07 8:30 [PATCH] x86_emulate: properly do IP updates and other side effects on success Jan Beulich
@ 2014-08-07 11:40 ` Andrew Cooper
2014-08-07 13:24 ` Fabio Fantoni
1 sibling, 0 replies; 11+ messages in thread
From: Andrew Cooper @ 2014-08-07 11:40 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: Keir Fraser
[-- Attachment #1.1: Type: text/plain, Size: 3410 bytes --]
On 07/08/14 09:30, Jan Beulich wrote:
> The two MMX/SSE/AVX code blocks failed to update IP properly, and these
> as well as get_reg_refix(), which "manually" updated IP so far, failed
> to do the TF and RF processing needed at the end of successfully
> emulated instructions.
>
> Reported-by: Andrei LUTAS <vlutas@bitdefender.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Andrew Cooper <andrew.cooper@citrix.com>
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -720,29 +720,26 @@ do{ uint8_t stub[] = { _bytes, 0xc3 };
> put_fpu(&fic); \
> } while (0)
>
> -static unsigned long __get_rep_prefix(
> - struct cpu_user_regs *int_regs,
> - struct cpu_user_regs *ext_regs,
> +static unsigned long _get_rep_prefix(
> + const struct cpu_user_regs *int_regs,
> int ad_bytes)
> {
> - unsigned long ecx = ((ad_bytes == 2) ? (uint16_t)int_regs->ecx :
> - (ad_bytes == 4) ? (uint32_t)int_regs->ecx :
> - int_regs->ecx);
> -
> - /* Skip the instruction if no repetitions are required. */
> - if ( ecx == 0 )
> - ext_regs->eip = int_regs->eip;
> -
> - return ecx;
> + return (ad_bytes == 2) ? (uint16_t)int_regs->ecx :
> + (ad_bytes == 4) ? (uint32_t)int_regs->ecx :
> + int_regs->ecx;
> }
>
> #define get_rep_prefix() ({ \
> unsigned long max_reps = 1; \
> if ( rep_prefix() ) \
> - max_reps = __get_rep_prefix(&_regs, ctxt->regs, ad_bytes); \
> + max_reps = _get_rep_prefix(&_regs, ad_bytes); \
> if ( max_reps == 0 ) \
> - goto done; \
> - max_reps; \
> + { \
> + /* Skip the instruction if no repetitions are required. */ \
> + dst.type = OP_NONE; \
> + goto writeback; \
> + } \
> + max_reps; \
> })
>
> static void __put_rep_prefix(
> @@ -3921,7 +3918,8 @@ x86_emulate(
> if ( !rc && (b & 1) && (ea.type == OP_MEM) )
> rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
> ea.bytes, ctxt);
> - goto done;
> + dst.type = OP_NONE;
> + break;
> }
>
> case 0x20: /* mov cr,reg */
> @@ -4188,7 +4186,8 @@ x86_emulate(
> if ( !rc && (b != 0x6f) && (ea.type == OP_MEM) )
> rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
> ea.bytes, ctxt);
> - goto done;
> + dst.type = OP_NONE;
> + break;
> }
>
> case 0x80 ... 0x8f: /* jcc (near) */ {
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 4431 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] 11+ messages in thread
* Re: [PATCH] x86_emulate: properly do IP updates and other side effects on success
2014-08-07 8:30 [PATCH] x86_emulate: properly do IP updates and other side effects on success Jan Beulich
2014-08-07 11:40 ` Andrew Cooper
@ 2014-08-07 13:24 ` Fabio Fantoni
2014-08-07 14:38 ` Jan Beulich
2014-08-07 14:40 ` Fabio Fantoni
1 sibling, 2 replies; 11+ messages in thread
From: Fabio Fantoni @ 2014-08-07 13:24 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: Keir Fraser
[-- Attachment #1: Type: text/plain, Size: 3899 bytes --]
Il 07/08/2014 10:30, Jan Beulich ha scritto:
> The two MMX/SSE/AVX code blocks failed to update IP properly, and these
> as well as get_reg_refix(), which "manually" updated IP so far, failed
> to do the TF and RF processing needed at the end of successfully
> emulated instructions.
>
> Reported-by: Andrei LUTAS <vlutas@bitdefender.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Thanks for the patch, I tested it to see if solves also qxl on linux
domUs problem but with this patch the domU crashes and I cannot get a
backtrace or specific errors.
xl create is ok, gdb on qemu close on domU's crash without having
backtrace and in xl dmesg I not saw errors.
Setting preserve always in xl cfg I can only see that crash and do a
core dump but I not know how to use it to take a backtrace or any other
useful information.
Someone can explain how to debug the problem for post all useful
informations please?
In attachment for now I put xl -vvv create and xl dmesg output.
Thanks for any reply and sorry for my bad english.
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -720,29 +720,26 @@ do{ uint8_t stub[] = { _bytes, 0xc3 };
> put_fpu(&fic); \
> } while (0)
>
> -static unsigned long __get_rep_prefix(
> - struct cpu_user_regs *int_regs,
> - struct cpu_user_regs *ext_regs,
> +static unsigned long _get_rep_prefix(
> + const struct cpu_user_regs *int_regs,
> int ad_bytes)
> {
> - unsigned long ecx = ((ad_bytes == 2) ? (uint16_t)int_regs->ecx :
> - (ad_bytes == 4) ? (uint32_t)int_regs->ecx :
> - int_regs->ecx);
> -
> - /* Skip the instruction if no repetitions are required. */
> - if ( ecx == 0 )
> - ext_regs->eip = int_regs->eip;
> -
> - return ecx;
> + return (ad_bytes == 2) ? (uint16_t)int_regs->ecx :
> + (ad_bytes == 4) ? (uint32_t)int_regs->ecx :
> + int_regs->ecx;
> }
>
> #define get_rep_prefix() ({ \
> unsigned long max_reps = 1; \
> if ( rep_prefix() ) \
> - max_reps = __get_rep_prefix(&_regs, ctxt->regs, ad_bytes); \
> + max_reps = _get_rep_prefix(&_regs, ad_bytes); \
> if ( max_reps == 0 ) \
> - goto done; \
> - max_reps; \
> + { \
> + /* Skip the instruction if no repetitions are required. */ \
> + dst.type = OP_NONE; \
> + goto writeback; \
> + } \
> + max_reps; \
> })
>
> static void __put_rep_prefix(
> @@ -3921,7 +3918,8 @@ x86_emulate(
> if ( !rc && (b & 1) && (ea.type == OP_MEM) )
> rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
> ea.bytes, ctxt);
> - goto done;
> + dst.type = OP_NONE;
> + break;
> }
>
> case 0x20: /* mov cr,reg */
> @@ -4188,7 +4186,8 @@ x86_emulate(
> if ( !rc && (b != 0x6f) && (ea.type == OP_MEM) )
> rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
> ea.bytes, ctxt);
> - goto done;
> + dst.type = OP_NONE;
> + break;
> }
>
> case 0x80 ... 0x8f: /* jcc (near) */ {
>
>
>
>
[-- Attachment #2: xl-vvv-create.txt --]
[-- Type: text/plain, Size: 10628 bytes --]
xl -vvv create /etc/xen/FEDORA19.cfg
Parsing config from /etc/xen/FEDORA19.cfg
libxl: debug: libxl_create.c:1436:do_domain_create: ao 0xfa55f0: create: how=(nil) callback=(nil) poller=0xfa5930
libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown
libxl: debug: libxl_device.c:197:disk_try_backend: Disk vdev=hda, backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:280:libxl__device_disk_set_backend: Disk vdev=hda, using backend qdisk
libxl: debug: libxl_create.c:896:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV domain, skipping bootloader
libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch w=0xfa5d28: deregister unregistered
xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x59b04
xc: detail: elf_parse_binary: memory: 0x100000 -> 0x159b04
xc: detail: VIRTUAL MEMORY ARRANGEMENT:
xc: detail: Loader: 0000000000100000->0000000000159b04
xc: detail: Modules: 0000000000000000->0000000000000000
xc: detail: TOTAL: 0000000000000000->0000000078000000
xc: detail: ENTRY: 0000000000100000
xc: detail: PHYSICAL MEMORY ALLOCATION:
xc: detail: 4KB PAGES: 0x0000000000000200
xc: detail: 2MB PAGES: 0x00000000000003bf
xc: detail: 1GB PAGES: 0x0000000000000000
xc: detail: elf_load_binary: phdr 0 at 0x7f10fce3a000 -> 0x7f10fce8aa9e
libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=qdisk
libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch w=0xfa7200: deregister unregistered
libxl: debug: libxl_dm.c:1321:libxl__spawn_local_dm: Spawning device-model /usr/lib/xen/bin/qemu-gdb with arguments:
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: /usr/lib/xen/bin/qemu-gdb
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -xen-domid
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: 1
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -chardev
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-1,server,nowait
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -mon
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: chardev=libxl-cmd,mode=control
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -nodefaults
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -name
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: FEDORA
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -k
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: it
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -spice
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: port=6002,tls-port=0,addr=0.0.0.0,disable-ticketing,agent-mouse=on,disable-copy-paste
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: virtio-serial
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -chardev
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: spicevmc,id=vdagent,name=vdagent
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: virtserialport,chardev=vdagent,name=com.redhat.spice.0
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: qxl-vga,vram_size_mb=64,ram_size_mb=64
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -boot
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: order=dc
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: ich9-usb-ehci1,id=usb,addr=0x1d.0x7,multifunction=on
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: ich9-usb-uhci1,masterbus=usb.0,firstport=0,addr=0x1d.0,multifunction=on
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: ich9-usb-uhci2,masterbus=usb.0,firstport=2,addr=0x1d.0x1,multifunction=on
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: ich9-usb-uhci3,masterbus=usb.0,firstport=4,addr=0x1d.0x2,multifunction=on
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -chardev
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: spicevmc,name=usbredir,id=usbrc1
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: usb-redir,chardev=usbrc1,id=usbrc1
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -chardev
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: spicevmc,name=usbredir,id=usbrc2
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: usb-redir,chardev=usbrc2,id=usbrc2
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -chardev
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: spicevmc,name=usbredir,id=usbrc3
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: usb-redir,chardev=usbrc3,id=usbrc3
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -chardev
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: spicevmc,name=usbredir,id=usbrc4
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: usb-redir,chardev=usbrc4,id=usbrc4
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -soundhw
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: hda
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -smp
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: 2,maxcpus=2
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -device
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: rtl8139,id=nic0,netdev=net0,mac=00:16:3e:76:c1:d0
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -netdev
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: type=tap,id=net0,ifname=vif1.0-emu,script=no,downscript=no
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -machine
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: xenfv
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -m
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: 1920
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: -drive
libxl: debug: libxl_dm.c:1323:libxl__spawn_local_dm: file=/mnt/vm/disks/FEDORA19.disk1.xm,if=ide,index=0,media=disk,format=raw,cache=writeback
libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch w=0xfa5f88 wpath=/local/domain/0/device-model/1/state token=3/0: register slotnum=3
libxl: debug: libxl_create.c:1450:do_domain_create: ao 0xfa55f0: inprogress: poller=0xfa5930, flags=i
libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xfa5f88 wpath=/local/domain/0/device-model/1/state token=3/0: event epath=/local/domain/0/device-model/1/state
libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xfa5f88 wpath=/local/domain/0/device-model/1/state token=3/0: event epath=/local/domain/0/device-model/1/state
libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch w=0xfa5f88 wpath=/local/domain/0/device-model/1/state token=3/0: deregister slotnum=3
libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch w=0xfa5f88: deregister unregistered
libxl: debug: libxl_qmp.c:691:libxl__qmp_initialize: connected to /var/run/xen/qmp-libxl-1
libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: qmp
libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
"execute": "qmp_capabilities",
"id": 1
}
'
libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
"execute": "query-chardev",
"id": 2
}
'
libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
libxl: debug: libxl_qmp.c:541:qmp_send_prepare: next qmp command: '{
"execute": "query-vnc",
"id": 3
}
'
libxl: debug: libxl_qmp.c:296:qmp_handle_response: message type: return
libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch w=0xfac0a8 wpath=/local/domain/0/backend/vif/1/0/state token=3/1: register slotnum=3
libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xfac0a8 wpath=/local/domain/0/backend/vif/1/0/state token=3/1: event epath=/local/domain/0/backend/vif/1/0/state
libxl: debug: libxl_event.c:810:devstate_watch_callback: backend /local/domain/0/backend/vif/1/0/state wanted state 2 still waiting state 1
libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0xfac0a8 wpath=/local/domain/0/backend/vif/1/0/state token=3/1: event epath=/local/domain/0/backend/vif/1/0/state
libxl: debug: libxl_event.c:806:devstate_watch_callback: backend /local/domain/0/backend/vif/1/0/state wanted state 2 ok
libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch w=0xfac0a8 wpath=/local/domain/0/backend/vif/1/0/state token=3/1: deregister slotnum=3
libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch w=0xfac0a8: deregister unregistered
libxl: debug: libxl_device.c:1004:device_hotplug: calling hotplug script: /etc/xen/scripts/vif-bridge online
libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to execute: /etc/xen/scripts/vif-bridge online
libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch w=0xfac130: deregister unregistered
libxl: debug: libxl_device.c:1004:device_hotplug: calling hotplug script: /etc/xen/scripts/vif-bridge add
libxl: debug: libxl_aoutils.c:513:libxl__async_exec_start: forking to execute: /etc/xen/scripts/vif-bridge add
libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch w=0xfac130: deregister unregistered
libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch w=0xfac130: deregister unregistered
libxl: debug: libxl_event.c:1909:libxl__ao_progress_report: ao 0xfa55f0: progress report: ignored
libxl: debug: libxl_event.c:1739:libxl__ao_complete: ao 0xfa55f0: complete, rc=0
libxl: debug: libxl_event.c:1711:libxl__ao__destroy: ao 0xfa55f0: destroy
xc: debug: hypercall buffer: total allocations:703 total releases:703
xc: debug: hypercall buffer: current allocations:0 maximum allocations:4
xc: debug: hypercall buffer: cache current size:4
xc: debug: hypercall buffer: cache hits:692 misses:4 toobig:7
xc: debug: hypercall buffer: total allocations:0 total releases:0
xc: debug: hypercall buffer: current allocations:0 maximum allocations:0
xc: debug: hypercall buffer: cache current size:0
xc: debug: hypercall buffer: cache hits:0 misses:0 toobig:0
[-- Attachment #3: xl-dmesg.txt --]
[-- Type: text/plain, Size: 5496 bytes --]
(d1) HVM Loader
(d1) Detected Xen v4.5-unstable
(d1) Xenbus rings @0xfeffc000, event channel 1
(d1) System requested SeaBIOS
(d1) CPU speed is 2660 MHz
(d1) Relocating guest memory for lowmem MMIO space disabled
(XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5
(d1) PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 10
(d1) PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:270: Dom1 PCI link 2 changed 0 -> 11
(d1) PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:270: Dom1 PCI link 3 changed 0 -> 5
(d1) PCI-ISA link 3 routed to IRQ5
(d1) pci dev 01:3 INTA->IRQ10
(d1) pci dev 02:0 INTA->IRQ11
(d1) pci dev 03:0 INTA->IRQ5
(d1) pci dev 04:0 INTA->IRQ5
(d1) pci dev 05:0 INTA->IRQ10
(d1) pci dev 06:0 INTA->IRQ11
(d1) pci dev 1d:0 INTA->IRQ10
(d1) pci dev 1d:1 INTB->IRQ11
(d1) pci dev 1d:2 INTC->IRQ5
(d1) pci dev 1d:7 INTD->IRQ5
(d1) No RAM in high memory; setting high_mem resource base to 100000000
(d1) pci dev 05:0 bar 10 size 004000000: 0f0000000
(d1) pci dev 05:0 bar 14 size 004000000: 0f4000000
(d1) pci dev 02:0 bar 14 size 001000000: 0f8000008
(d1) pci dev 06:0 bar 30 size 000040000: 0f9000000
(d1) pci dev 05:0 bar 30 size 000010000: 0f9040000
(d1) pci dev 03:0 bar 10 size 000004000: 0f9050000
(d1) pci dev 05:0 bar 18 size 000002000: 0f9054000
(d1) pci dev 04:0 bar 14 size 000001000: 0f9056000
(d1) pci dev 1d:7 bar 10 size 000001000: 0f9057000
(d1) pci dev 02:0 bar 10 size 000000100: 00000c001
(d1) pci dev 06:0 bar 10 size 000000100: 00000c101
(d1) pci dev 06:0 bar 14 size 000000100: 0f9058000
(d1) pci dev 04:0 bar 10 size 000000020: 00000c201
(d1) pci dev 05:0 bar 1c size 000000020: 00000c221
(d1) pci dev 1d:0 bar 20 size 000000020: 00000c241
(d1) pci dev 1d:1 bar 20 size 000000020: 00000c261
(d1) pci dev 1d:2 bar 20 size 000000020: 00000c281
(d1) pci dev 01:1 bar 20 size 000000010: 00000c2a1
(d1) Multiprocessor initialisation:
(d1) - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1) - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d1) Testing HVM environment:
(d1) - REP INSB across page boundaries ... passed
(d1) - GS base MSRs and SWAPGS ... passed
(d1) Passed 2 of 2 tests
(d1) Writing SMBIOS tables ...
(d1) Loading SeaBIOS ...
(d1) Creating MP tables ...
(d1) Loading ACPI ...
(d1) rmvc_pcrm is dfffffdc
(d1) vm86 TSS at fc00a200
(d1) BIOS map:
(d1) 10000-100d3: Scratch space
(d1) c0000-fffff: Main BIOS
(d1) E820 table:
(d1) [00]: 00000000:00000000 - 00000000:000a0000: RAM
(d1) HOLE: 00000000:000a0000 - 00000000:000c0000
(d1) [01]: 00000000:000c0000 - 00000000:00100000: RESERVED
(d1) [02]: 00000000:00100000 - 00000000:78000000: RAM
(d1) HOLE: 00000000:78000000 - 00000000:fc000000
(d1) [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
(d1) Invoking SeaBIOS ...
(d1) SeaBIOS (version debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
(d1)
(d1) Found Xen hypervisor signature at 40000000
(d1) Running on QEMU (i440fx)
(d1) xen: copy e820...
(d1) Relocating init from 0x000df619 to 0x77fae600 (size 71995)
(d1) CPU Mhz=2660
(d1) Found 13 PCI devices (max PCI bus is 00)
(d1) Allocated Xen hypercall page at 77fff000
(d1) Detected Xen v4.5-unstable
(d1) xen: copy BIOS tables...
(d1) Copying SMBIOS entry point from 0x00010010 to 0x000f0f40
(d1) Copying MPTABLE from 0xfc001170/fc001180 to 0x000f0e40
(d1) Copying PIR from 0x00010030 to 0x000f0dc0
(d1) Copying ACPI RSDP from 0x000100b0 to 0x000f0d90
(d1) Using pmtimer, ioport 0xb008
(d1) Scan for VGA option rom
(d1) Running option rom at c000:0003
(XEN) stdvga.c:147:d1v0 entering stdvga and caching modes
(d1) pmm call arg1=0
(d1) Turning on vga text mode console
(d1) SeaBIOS (version debian/1.7.5-1-0-g506b58d-20140603_102943-testVS01OU)
(d1) Machine UUID 56875ea9-ac92-41b0-8ac8-ef74615bdad7
(d1) EHCI init on dev 00:1d.7 (regs=0xf9057020)
(d1) Found 0 lpt ports
(d1) Found 0 serial ports
(d1) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9)
(d1) ATA controller 2 at 170/374/0 (irq 15 dev 9)
(d1) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (10000 MiBytes)
(d1) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0
(d1) UHCI init on dev 00:1d.0 (io=c240)
(d1) UHCI init on dev 00:1d.1 (io=c260)
(d1) UHCI init on dev 00:1d.2 (io=c280)
(d1) PS2 keyboard initialized
(d1) All threads complete.
(d1) Scan for option roms
(d1) Running option rom at c980:0003
(d1) pmm call arg1=1
(d1) pmm call arg1=0
(d1) pmm call arg1=1
(d1) pmm call arg1=0
(d1) Searching bootorder for: /pci@i0cf8/*@6
(d1)
(d1) Press F12 for boot menu.
(d1)
(d1) Searching bootorder for: HALT
(d1) drive 0x000f0d40: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=20480000
(d1) Space available for UMB: ca800-ef000, f0000-f0d40
(d1) Returned 258048 bytes of ZoneHigh
(d1) e820 map has 6 items:
(d1) 0: 0000000000000000 - 000000000009fc00 = 1 RAM
(d1) 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
(d1) 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
(d1) 3: 0000000000100000 - 0000000077fff000 = 1 RAM
(d1) 4: 0000000077fff000 - 0000000078000000 = 2 RESERVED
(d1) 5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
(d1) enter handle_19:
(d1) NULL
(d1) Booting from Hard Disk...
(d1) Booting from 0000:7c00
(XEN) irq.c:380: Dom1 callback via changed to Direct Vector 0xf3
(XEN) irq.c:270: Dom1 PCI link 0 changed 5 -> 0
(XEN) irq.c:270: Dom1 PCI link 1 changed 10 -> 0
(XEN) irq.c:270: Dom1 PCI link 2 changed 11 -> 0
(XEN) irq.c:270: Dom1 PCI link 3 changed 5 -> 0
(XEN) grant_table.c:295:d0v0 Increased maptrack size to 2 frames
[-- Attachment #4: 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] 11+ messages in thread
* Re: [PATCH] x86_emulate: properly do IP updates and other side effects on success
2014-08-07 13:24 ` Fabio Fantoni
@ 2014-08-07 14:38 ` Jan Beulich
2014-08-07 14:57 ` Fabio Fantoni
2014-08-07 14:40 ` Fabio Fantoni
1 sibling, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2014-08-07 14:38 UTC (permalink / raw)
To: Fabio Fantoni; +Cc: xen-devel, Keir Fraser
>>> On 07.08.14 at 15:24, <fabio.fantoni@m2r.biz> wrote:
> Il 07/08/2014 10:30, Jan Beulich ha scritto:
>> The two MMX/SSE/AVX code blocks failed to update IP properly, and these
>> as well as get_reg_refix(), which "manually" updated IP so far, failed
>> to do the TF and RF processing needed at the end of successfully
>> emulated instructions.
>>
>> Reported-by: Andrei LUTAS <vlutas@bitdefender.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>
> Thanks for the patch, I tested it to see if solves also qxl on linux
> domUs problem but with this patch the domU crashes and I cannot get a
> backtrace or specific errors.
Are you saying that this is different from without that patch?
Considering the lack of EIP update, the emulation of the
instructions in question can't have done much good before,
and - just like the reporters of the issue saw - the guest should
have hung.
Jan
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86_emulate: properly do IP updates and other side effects on success
2014-08-07 13:24 ` Fabio Fantoni
2014-08-07 14:38 ` Jan Beulich
@ 2014-08-07 14:40 ` Fabio Fantoni
1 sibling, 0 replies; 11+ messages in thread
From: Fabio Fantoni @ 2014-08-07 14:40 UTC (permalink / raw)
To: Jan Beulich, xen-devel; +Cc: Keir Fraser
Il 07/08/2014 15:24, Fabio Fantoni ha scritto:
> Il 07/08/2014 10:30, Jan Beulich ha scritto:
>> The two MMX/SSE/AVX code blocks failed to update IP properly, and these
>> as well as get_reg_refix(), which "manually" updated IP so far, failed
>> to do the TF and RF processing needed at the end of successfully
>> emulated instructions.
>>
>> Reported-by: Andrei LUTAS <vlutas@bitdefender.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>
> Thanks for the patch, I tested it to see if solves also qxl on linux
> domUs problem but with this patch the domU crashes and I cannot get a
> backtrace or specific errors.
> xl create is ok, gdb on qemu close on domU's crash without having
> backtrace and in xl dmesg I not saw errors.
> Setting preserve always in xl cfg I can only see that crash and do a
> core dump but I not know how to use it to take a backtrace or any
> other useful information.
> Someone can explain how to debug the problem for post all useful
> informations please?
> In attachment for now I put xl -vvv create and xl dmesg output.
>
> Thanks for any reply and sorry for my bad english.
Now I also tried gdbsx:
gdbsx -a 2 64 9999
...
(gdb) target remote localhost:9999
Remote debugging using localhost:9999
[Switching to Remote target]
0x66666666 in ?? ()
(gdb) c
Continuing.
Program received signal SIGINT, Interrupt.
0x000000ff in ?? ()
(gdb) bt full
#0 0x000000ff in ?? ()
No symbol table info available.
Cannot access memory at address 0x6d2966c0
I not know if what I did is correct.
>
>>
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -720,29 +720,26 @@ do{ uint8_t stub[] = { _bytes, 0xc3 };
>> put_fpu(&fic); \
>> } while (0)
>> -static unsigned long __get_rep_prefix(
>> - struct cpu_user_regs *int_regs,
>> - struct cpu_user_regs *ext_regs,
>> +static unsigned long _get_rep_prefix(
>> + const struct cpu_user_regs *int_regs,
>> int ad_bytes)
>> {
>> - unsigned long ecx = ((ad_bytes == 2) ? (uint16_t)int_regs->ecx :
>> - (ad_bytes == 4) ? (uint32_t)int_regs->ecx :
>> - int_regs->ecx);
>> -
>> - /* Skip the instruction if no repetitions are required. */
>> - if ( ecx == 0 )
>> - ext_regs->eip = int_regs->eip;
>> -
>> - return ecx;
>> + return (ad_bytes == 2) ? (uint16_t)int_regs->ecx :
>> + (ad_bytes == 4) ? (uint32_t)int_regs->ecx :
>> + int_regs->ecx;
>> }
>> #define get_rep_prefix()
>> ({ \
>> unsigned long max_reps =
>> 1; \
>> if ( rep_prefix()
>> ) \
>> - max_reps = __get_rep_prefix(&_regs, ctxt->regs,
>> ad_bytes); \
>> + max_reps = _get_rep_prefix(&_regs,
>> ad_bytes); \
>> if ( max_reps == 0
>> ) \
>> - goto
>> done; \
>> - max_reps; \
>> + { \
>> + /* Skip the instruction if no repetitions are required.
>> */ \
>> + dst.type =
>> OP_NONE; \
>> + goto
>> writeback; \
>> + } \
>> + max_reps; \
>> })
>> static void __put_rep_prefix(
>> @@ -3921,7 +3918,8 @@ x86_emulate(
>> if ( !rc && (b & 1) && (ea.type == OP_MEM) )
>> rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
>> ea.bytes, ctxt);
>> - goto done;
>> + dst.type = OP_NONE;
>> + break;
>> }
>> case 0x20: /* mov cr,reg */
>> @@ -4188,7 +4186,8 @@ x86_emulate(
>> if ( !rc && (b != 0x6f) && (ea.type == OP_MEM) )
>> rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
>> ea.bytes, ctxt);
>> - goto done;
>> + dst.type = OP_NONE;
>> + break;
>> }
>> case 0x80 ... 0x8f: /* jcc (near) */ {
>>
>>
>>
>>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86_emulate: properly do IP updates and other side effects on success
2014-08-07 14:38 ` Jan Beulich
@ 2014-08-07 14:57 ` Fabio Fantoni
2014-08-11 12:53 ` Fabio Fantoni
0 siblings, 1 reply; 11+ messages in thread
From: Fabio Fantoni @ 2014-08-07 14:57 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Keir Fraser
Il 07/08/2014 16:38, Jan Beulich ha scritto:
>>>> On 07.08.14 at 15:24, <fabio.fantoni@m2r.biz> wrote:
>> Il 07/08/2014 10:30, Jan Beulich ha scritto:
>>> The two MMX/SSE/AVX code blocks failed to update IP properly, and these
>>> as well as get_reg_refix(), which "manually" updated IP so far, failed
>>> to do the TF and RF processing needed at the end of successfully
>>> emulated instructions.
>>>
>>> Reported-by: Andrei LUTAS <vlutas@bitdefender.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>> Thanks for the patch, I tested it to see if solves also qxl on linux
>> domUs problem but with this patch the domU crashes and I cannot get a
>> backtrace or specific errors.
> Are you saying that this is different from without that patch?
> Considering the lack of EIP update, the emulation of the
> instructions in question can't have done much good before,
> and - just like the reporters of the issue saw - the guest should
> have hung.
>
> Jan
>
Before this patch the domU's org was always 100% cpu, spice show black
screen and is possible a xl shutdown, after at xorg start, show domU's
mouse in center in spice and domU crash.
I'm unable to debug it, can you tell me what I must do to debug it and
give you all possibile information?
This is the exact git I used for my tests:
https://github.com/Fantu/Xen/tree/rebase/m2r-staging
Contains some libxl patch about spice used for a long time and with only
qxl problem on linux domUs (with windows domUs is working good since
your patch of long time ago about similar istructions and same
performance as kvm after one or more patches in xen-unstable that I not
know exactly and is still working also with this patch).
Thanks for any reply and sorry for my bad english.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86_emulate: properly do IP updates and other side effects on success
2014-08-07 14:57 ` Fabio Fantoni
@ 2014-08-11 12:53 ` Fabio Fantoni
2014-08-11 13:16 ` Fabio Fantoni
0 siblings, 1 reply; 11+ messages in thread
From: Fabio Fantoni @ 2014-08-11 12:53 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Keir Fraser
Il 07/08/2014 16:57, Fabio Fantoni ha scritto:
> Il 07/08/2014 16:38, Jan Beulich ha scritto:
>>>>> On 07.08.14 at 15:24, <fabio.fantoni@m2r.biz> wrote:
>>> Il 07/08/2014 10:30, Jan Beulich ha scritto:
>>>> The two MMX/SSE/AVX code blocks failed to update IP properly, and
>>>> these
>>>> as well as get_reg_refix(), which "manually" updated IP so far, failed
>>>> to do the TF and RF processing needed at the end of successfully
>>>> emulated instructions.
>>>>
>>>> Reported-by: Andrei LUTAS <vlutas@bitdefender.com>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>> Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>> Thanks for the patch, I tested it to see if solves also qxl on linux
>>> domUs problem but with this patch the domU crashes and I cannot get a
>>> backtrace or specific errors.
>> Are you saying that this is different from without that patch?
>> Considering the lack of EIP update, the emulation of the
>> instructions in question can't have done much good before,
>> and - just like the reporters of the issue saw - the guest should
>> have hung.
>>
>> Jan
>>
>
> Before this patch the domU's org was always 100% cpu, spice show black
> screen and is possible a xl shutdown, after at xorg start, show domU's
> mouse in center in spice and domU crash.
> I'm unable to debug it, can you tell me what I must do to debug it and
> give you all possibile information?
>
> This is the exact git I used for my tests:
> https://github.com/Fantu/Xen/tree/rebase/m2r-staging
> Contains some libxl patch about spice used for a long time and with
> only qxl problem on linux domUs (with windows domUs is working good
> since your patch of long time ago about similar istructions and same
> performance as kvm after one or more patches in xen-unstable that I
> not know exactly and is still working also with this patch).
>
> Thanks for any reply and sorry for my bad english.
Someone can tell me how to debug the domU's crash please?
Thanks for any reply and sorry for my bad english.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86_emulate: properly do IP updates and other side effects on success
2014-08-11 12:53 ` Fabio Fantoni
@ 2014-08-11 13:16 ` Fabio Fantoni
2014-08-11 13:32 ` Andrew Cooper
2014-08-11 14:14 ` Jan Beulich
0 siblings, 2 replies; 11+ messages in thread
From: Fabio Fantoni @ 2014-08-11 13:16 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Keir Fraser
Il 11/08/2014 14:53, Fabio Fantoni ha scritto:
> Il 07/08/2014 16:57, Fabio Fantoni ha scritto:
>> Il 07/08/2014 16:38, Jan Beulich ha scritto:
>>>>>> On 07.08.14 at 15:24, <fabio.fantoni@m2r.biz> wrote:
>>>> Il 07/08/2014 10:30, Jan Beulich ha scritto:
>>>>> The two MMX/SSE/AVX code blocks failed to update IP properly, and
>>>>> these
>>>>> as well as get_reg_refix(), which "manually" updated IP so far,
>>>>> failed
>>>>> to do the TF and RF processing needed at the end of successfully
>>>>> emulated instructions.
>>>>>
>>>>> Reported-by: Andrei LUTAS <vlutas@bitdefender.com>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>> Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>>> Thanks for the patch, I tested it to see if solves also qxl on linux
>>>> domUs problem but with this patch the domU crashes and I cannot get a
>>>> backtrace or specific errors.
>>> Are you saying that this is different from without that patch?
>>> Considering the lack of EIP update, the emulation of the
>>> instructions in question can't have done much good before,
>>> and - just like the reporters of the issue saw - the guest should
>>> have hung.
>>>
>>> Jan
>>>
>>
>> Before this patch the domU's org was always 100% cpu, spice show
>> black screen and is possible a xl shutdown, after at xorg start, show
>> domU's mouse in center in spice and domU crash.
>> I'm unable to debug it, can you tell me what I must do to debug it
>> and give you all possibile information?
>>
>> This is the exact git I used for my tests:
>> https://github.com/Fantu/Xen/tree/rebase/m2r-staging
>> Contains some libxl patch about spice used for a long time and with
>> only qxl problem on linux domUs (with windows domUs is working good
>> since your patch of long time ago about similar istructions and same
>> performance as kvm after one or more patches in xen-unstable that I
>> not know exactly and is still working also with this patch).
>>
>> Thanks for any reply and sorry for my bad english.
>
> Someone can tell me how to debug the domU's crash please?
>
> Thanks for any reply and sorry for my bad english.
Now I did also a vcpus dump on domU preserved after crash if can be
useful for this problem probably about cpu's instructions emulation:
gdbsx -c 1 64
===> Context for DOMID:1
--> VCPU:0
rip:ffffffff810013a8 rsp:ffff880074803b30 flags:0000000000000092
rax:0000000000000000 rbx:00000000fffffffe rcx:00000000ffffffff
rdx:ffffffff81edc300 rsi:ffff880074803b3c rdi:0000000000000002
r08:0000000000000000 r09:0000000000000002 r10:ffffffff81d0a5e0
r11:ffff8800748038c6 r12:ffffffff81c515c0 r13:0000000000000000
r14:ffffffff81edc300 r15:0000000000000000 rbp:ffff880074803b40
cs:0000000000000010 ds:0000000000000000 fs:0000000000000000
gs:0000000000000000
Call Trace:
[ffffffff810013a8]
[ffffffff8100357e]
[ffffffff810035a3]
[ffffffff816fa43c]
[ffffffff81a07727]
[ffffffff816fa49a]
[ffffffff816eb027]
[ffffffff810e17c8]
[ffffffff816f7603]
[ffffffff81a073db]
[ffffffff81016f9b]
--> VCPU:1
rip:ffffffff81053585 rsp:ffff880074823f88 flags:0000000000000046
rax:ffffffff81c2a160 rbx:ffff88007342ffd8 rcx:00000006867023fa
rdx:0000000000bad748 rsi:00000000000000ff rdi:00000000000000f0
r08:00000000000000ac r09:0000000000000000 r10:0000000000000400
r11:0000000000000001 r12:0000000000000001 r13:0000000000000000
r14:ffff88007342c000 r15:ffff88007342ffd8 rbp:ffff880074823f88
cs:0000000000000010 ds:0000000000000000 fs:0000000000000000
gs:0000000000000000
Call Trace:
[ffffffff81053585]
[ffffffff8101d70d]
[ffffffff810433b9]
[ffffffff8170005d]
[ffffffffffffffff]
[ffffffff810afd40]
[ffffffff8100a410]
[ffffffff8100a020]
[ffffffff81a06d7f]
[ffffffff8180b180]
[ffffffff81c2a858]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86_emulate: properly do IP updates and other side effects on success
2014-08-11 13:16 ` Fabio Fantoni
@ 2014-08-11 13:32 ` Andrew Cooper
2014-08-11 14:14 ` Jan Beulich
1 sibling, 0 replies; 11+ messages in thread
From: Andrew Cooper @ 2014-08-11 13:32 UTC (permalink / raw)
To: Fabio Fantoni, Jan Beulich; +Cc: xen-devel, Keir Fraser
On 11/08/14 14:16, Fabio Fantoni wrote:
> Il 11/08/2014 14:53, Fabio Fantoni ha scritto:
>> Il 07/08/2014 16:57, Fabio Fantoni ha scritto:
>>> Il 07/08/2014 16:38, Jan Beulich ha scritto:
>>>>>>> On 07.08.14 at 15:24, <fabio.fantoni@m2r.biz> wrote:
>>>>> Il 07/08/2014 10:30, Jan Beulich ha scritto:
>>>>>> The two MMX/SSE/AVX code blocks failed to update IP properly, and
>>>>>> these
>>>>>> as well as get_reg_refix(), which "manually" updated IP so far,
>>>>>> failed
>>>>>> to do the TF and RF processing needed at the end of successfully
>>>>>> emulated instructions.
>>>>>>
>>>>>> Reported-by: Andrei LUTAS <vlutas@bitdefender.com>
>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>> Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>>>> Thanks for the patch, I tested it to see if solves also qxl on linux
>>>>> domUs problem but with this patch the domU crashes and I cannot get a
>>>>> backtrace or specific errors.
>>>> Are you saying that this is different from without that patch?
>>>> Considering the lack of EIP update, the emulation of the
>>>> instructions in question can't have done much good before,
>>>> and - just like the reporters of the issue saw - the guest should
>>>> have hung.
>>>>
>>>> Jan
>>>>
>>>
>>> Before this patch the domU's org was always 100% cpu, spice show
>>> black screen and is possible a xl shutdown, after at xorg start,
>>> show domU's mouse in center in spice and domU crash.
>>> I'm unable to debug it, can you tell me what I must do to debug it
>>> and give you all possibile information?
>>>
>>> This is the exact git I used for my tests:
>>> https://github.com/Fantu/Xen/tree/rebase/m2r-staging
>>> Contains some libxl patch about spice used for a long time and with
>>> only qxl problem on linux domUs (with windows domUs is working good
>>> since your patch of long time ago about similar istructions and same
>>> performance as kvm after one or more patches in xen-unstable that I
>>> not know exactly and is still working also with this patch).
>>>
>>> Thanks for any reply and sorry for my bad english.
>>
>> Someone can tell me how to debug the domU's crash please?
>>
>> Thanks for any reply and sorry for my bad english.
>
> Now I did also a vcpus dump on domU preserved after crash if can be
> useful for this problem probably about cpu's instructions emulation:
> gdbsx -c 1 64
> ===> Context for DOMID:1
>
> --> VCPU:0
SHEDOP_shutdown. Shutdown code in a structure at ffff880074803b3c
Looks like the VM has crashed.
~Andrew
> rip:ffffffff810013a8 rsp:ffff880074803b30 flags:0000000000000092
> rax:0000000000000000 rbx:00000000fffffffe rcx:00000000ffffffff
> rdx:ffffffff81edc300 rsi:ffff880074803b3c rdi:0000000000000002
> r08:0000000000000000 r09:0000000000000002 r10:ffffffff81d0a5e0
> r11:ffff8800748038c6 r12:ffffffff81c515c0 r13:0000000000000000
> r14:ffffffff81edc300 r15:0000000000000000 rbp:ffff880074803b40
> cs:0000000000000010 ds:0000000000000000 fs:0000000000000000
> gs:0000000000000000
>
> Call Trace:
> [ffffffff810013a8]
> [ffffffff8100357e]
> [ffffffff810035a3]
> [ffffffff816fa43c]
> [ffffffff81a07727]
> [ffffffff816fa49a]
> [ffffffff816eb027]
> [ffffffff810e17c8]
> [ffffffff816f7603]
> [ffffffff81a073db]
> [ffffffff81016f9b]
>
> --> VCPU:1
> rip:ffffffff81053585 rsp:ffff880074823f88 flags:0000000000000046
> rax:ffffffff81c2a160 rbx:ffff88007342ffd8 rcx:00000006867023fa
> rdx:0000000000bad748 rsi:00000000000000ff rdi:00000000000000f0
> r08:00000000000000ac r09:0000000000000000 r10:0000000000000400
> r11:0000000000000001 r12:0000000000000001 r13:0000000000000000
> r14:ffff88007342c000 r15:ffff88007342ffd8 rbp:ffff880074823f88
> cs:0000000000000010 ds:0000000000000000 fs:0000000000000000
> gs:0000000000000000
>
> Call Trace:
> [ffffffff81053585]
> [ffffffff8101d70d]
> [ffffffff810433b9]
> [ffffffff8170005d]
> [ffffffffffffffff]
> [ffffffff810afd40]
> [ffffffff8100a410]
> [ffffffff8100a020]
> [ffffffff81a06d7f]
> [ffffffff8180b180]
> [ffffffff81c2a858]
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86_emulate: properly do IP updates and other side effects on success
2014-08-11 13:16 ` Fabio Fantoni
2014-08-11 13:32 ` Andrew Cooper
@ 2014-08-11 14:14 ` Jan Beulich
2014-08-11 14:31 ` Fabio Fantoni
1 sibling, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2014-08-11 14:14 UTC (permalink / raw)
To: Fabio Fantoni; +Cc: xen-devel, Keir Fraser
>>> On 11.08.14 at 15:16, <fabio.fantoni@m2r.biz> wrote:
> Now I did also a vcpus dump on domU preserved after crash if can be
> useful for this problem probably about cpu's instructions emulation:
That's certainly a necessary step, but without telling us the instruction
under emulation (assuming there is one being emulated) by resolving
the dumped RIP values and ...
> gdbsx -c 1 64
> ===> Context for DOMID:1
>
> --> VCPU:0
> rip:ffffffff810013a8 rsp:ffff880074803b30 flags:0000000000000092
> rax:0000000000000000 rbx:00000000fffffffe rcx:00000000ffffffff
> rdx:ffffffff81edc300 rsi:ffff880074803b3c rdi:0000000000000002
> r08:0000000000000000 r09:0000000000000002 r10:ffffffff81d0a5e0
> r11:ffff8800748038c6 r12:ffffffff81c515c0 r13:0000000000000000
> r14:ffffffff81edc300 r15:0000000000000000 rbp:ffff880074803b40
> cs:0000000000000010 ds:0000000000000000 fs:0000000000000000
> gs:0000000000000000
>
> Call Trace:
> [ffffffff810013a8]
> [ffffffff8100357e]
> [ffffffff810035a3]
> [ffffffff816fa43c]
> [ffffffff81a07727]
> [ffffffff816fa49a]
> [ffffffff816eb027]
> [ffffffff810e17c8]
> [ffffffff816f7603]
> [ffffffff81a073db]
> [ffffffff81016f9b]
... perhaps resolving these addresses so we can associated a
meaning to them I don't think there's much we can do with this data.
Jan
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86_emulate: properly do IP updates and other side effects on success
2014-08-11 14:14 ` Jan Beulich
@ 2014-08-11 14:31 ` Fabio Fantoni
0 siblings, 0 replies; 11+ messages in thread
From: Fabio Fantoni @ 2014-08-11 14:31 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Keir Fraser
Il 11/08/2014 16:14, Jan Beulich ha scritto:
>>>> On 11.08.14 at 15:16, <fabio.fantoni@m2r.biz> wrote:
>> Now I did also a vcpus dump on domU preserved after crash if can be
>> useful for this problem probably about cpu's instructions emulation:
> That's certainly a necessary step, but without telling us the instruction
> under emulation (assuming there is one being emulated) by resolving
> the dumped RIP values and ...
>
>> gdbsx -c 1 64
>> ===> Context for DOMID:1
>>
>> --> VCPU:0
>> rip:ffffffff810013a8 rsp:ffff880074803b30 flags:0000000000000092
>> rax:0000000000000000 rbx:00000000fffffffe rcx:00000000ffffffff
>> rdx:ffffffff81edc300 rsi:ffff880074803b3c rdi:0000000000000002
>> r08:0000000000000000 r09:0000000000000002 r10:ffffffff81d0a5e0
>> r11:ffff8800748038c6 r12:ffffffff81c515c0 r13:0000000000000000
>> r14:ffffffff81edc300 r15:0000000000000000 rbp:ffff880074803b40
>> cs:0000000000000010 ds:0000000000000000 fs:0000000000000000
>> gs:0000000000000000
>>
>> Call Trace:
>> [ffffffff810013a8]
>> [ffffffff8100357e]
>> [ffffffff810035a3]
>> [ffffffff816fa43c]
>> [ffffffff81a07727]
>> [ffffffff816fa49a]
>> [ffffffff816eb027]
>> [ffffffff810e17c8]
>> [ffffffff816f7603]
>> [ffffffff81a073db]
>> [ffffffff81016f9b]
> ... perhaps resolving these addresses so we can associated a
> meaning to them I don't think there's much we can do with this data.
>
> Jan
>
Thanks for your reply.
Can you give me an how-to for take all data you need?
I tried also gdbsx to try catch one full backtrace of domU's crash but
seems that was failed:
http://lists.xen.org/archives/html/xen-devel/2014-08/msg00801.html
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-08-11 14:30 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-07 8:30 [PATCH] x86_emulate: properly do IP updates and other side effects on success Jan Beulich
2014-08-07 11:40 ` Andrew Cooper
2014-08-07 13:24 ` Fabio Fantoni
2014-08-07 14:38 ` Jan Beulich
2014-08-07 14:57 ` Fabio Fantoni
2014-08-11 12:53 ` Fabio Fantoni
2014-08-11 13:16 ` Fabio Fantoni
2014-08-11 13:32 ` Andrew Cooper
2014-08-11 14:14 ` Jan Beulich
2014-08-11 14:31 ` Fabio Fantoni
2014-08-07 14:40 ` Fabio Fantoni
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).