diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1705 | 81 | ||||
| -rw-r--r-- | results/classifier/108/other/1705118 | 173 | ||||
| -rw-r--r-- | results/classifier/108/other/1705717 | 78 |
3 files changed, 332 insertions, 0 deletions
diff --git a/results/classifier/108/other/1705 b/results/classifier/108/other/1705 new file mode 100644 index 00000000..63491575 --- /dev/null +++ b/results/classifier/108/other/1705 @@ -0,0 +1,81 @@ +PID: 0.865 +debug: 0.831 +graphic: 0.829 +permissions: 0.803 +vnc: 0.789 +semantic: 0.785 +device: 0.781 +performance: 0.778 +boot: 0.745 +files: 0.729 +other: 0.726 +network: 0.725 +KVM: 0.699 +socket: 0.679 + +Illegal instruction when I want to numactl --cpubind=0 --membind=1 to CXL Memory +Description of problem: +I ran QEMU for simulating CXL DRAM and when I tried to run `numactl --cpubind=0 --membind=1 ls` , I got `Illegal instruction` +The numa node 1 was the CXL DRAM simulated by QEMU. + +> root@8003:~# numactl -H +> available: 2 nodes (0-1) +> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 +> node 0 size: 32090 MB +> node 0 free: 31325 MB +> node 1 cpus: +> node 1 size: 32768 MB +> node 1 free: 32768 MB +> node distances: +> node 0 1 +> 0: 10 20 +> 1: 20 10 + +When I ran on numa node 1, no failed + +> root@8003:~# numactl --membind=0 ls +> ndctl + +When I ran on numa node 1(CXL DRAM),it failed. + +> root@8003:~# numactl --membind=1 ls +> [ 913.975032] traps: ls[667] trap invalid opcode ip:7fdec255d180 sp:7ffd3c507288 error:0 in ld-linux-x86-64.so.2[7fdec2546000+2a000] +> **Illegal instruction** +Steps to reproduce: +1. start the guest +2. cxl list (we could see the simulated CXL DRAM) +> root@8003:~# cxl list +> [ +> { +> "memdev":"mem0", +> "ram_size":34359738368, +> "serial":0, +> "host":"0000:0d:00.0" +> } +> ] +3. cxl create-region -t ram -d decoder0.0 -m mem0 +4. daxctl reconfigure-device dax0.0 --mode=system-ram +5. numactl -H +> root@8003:~# numactl -H +> available: 2 nodes (0-1) +> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 +> node 0 size: 32090 MB +> node 0 fr +> ee: 31254 MB +> node 1 cpus: +> node 1 size: 32768 MB +> node 1 free: 32768 MB +> node distances: +> node 0 1 +> 0: 10 20 +> 1: 20 10 +6. numactl --membind=1 ls +> root@8003:~# numactl --membind=1 ls +> [38441.892140] **traps: ls[861] trap invalid opcode ip:7f15db6ac180 sp:7ffc648755c8 **error:0 in ld-linux-x86-64.so.2[7f15db695000+2a000] +> **Illegal instruction** +Additional information: +When I run dmesg, I found an error. +> root@8003:~# dmesg|grep error +> [ 2.321130] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 + +Since my CPU is a Xeon III, not a Xeon IV with CXL support, **I'm wondering if it's because the CPU doesn't support CXL instructions, or if the Xeon III can emulate it, just because my settings don't make sense**. If this is my settings problem, could you help me to deal this? Or it just caused by my Xeon III,I will update it to Xeon IV. diff --git a/results/classifier/108/other/1705118 b/results/classifier/108/other/1705118 new file mode 100644 index 00000000..4b579054 --- /dev/null +++ b/results/classifier/108/other/1705118 @@ -0,0 +1,173 @@ +other: 0.866 +graphic: 0.819 +vnc: 0.799 +debug: 0.790 +device: 0.758 +KVM: 0.754 +semantic: 0.753 +permissions: 0.742 +performance: 0.737 +PID: 0.736 +socket: 0.706 +network: 0.682 +files: 0.667 +boot: 0.662 + +qemu user mode: rt signals not implemented for sparc guests + +The documentation +<https://qemu.weilnetz.de/doc/qemu-doc.html#Features> says that +qemu in user mode supports POSIX signal handling. + +Catching SIGSEGV according to POSIX, however, does not work on + ppc, ppc64, ppc64le, s390x, sparc64. +It does work, however, on + aarch64, alpha, arm, hppa, m68k, mips, mips64, sh4. + +How to reproduce: +The attached program runs fine (exits with code 0) on + - real hardware Linux/PowerPC64 (in 32-bit and 64-bit mode), + - real hardware Linux/PowerPC64LE, + - qemu-system-s390x emulated Linux/s390x, + - real hardware Linux/SPARC64. +$ gcc -O -Wall testsigsegv.c; ./a.out; echo $? +0 + +For ppc: +$ powerpc-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-ppc +$ ~/inst-qemu/2.9.0/bin/qemu-ppc testsigsegv-ppc +$ echo $? +3 + +For ppc64: +$ powerpc64-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-ppc64 +$ ~/inst-qemu/2.9.0/bin/qemu-ppc64 testsigsegv-ppc64 +$ echo $? +3 + +For ppc64le: +$ powerpc64le-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-ppc64le +$ ~/inst-qemu/2.9.0/bin/qemu-ppc64le testsigsegv-ppc64le +$ echo $? +3 + +For s390x: +$ s390x-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-s390x +$ ~/inst-qemu/2.9.0/bin/qemu-s390x testsigsegv-s390x +$ echo $? +3 +$ s390x-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -DAVOID_LINUX_S390X_COMPAT -o testsigsegv-s390x-a +$ ~/inst-qemu/2.9.0/bin/qemu-s390x testsigsegv-s390x-a +$ echo $? +0 +So, the test fails here because the Linux/s390x kernel omits the least +significant 12 bits of the fault address in the 'si_addr' field. But +qemu-s390x is not compatible with the Linux/s390x behaviour: it puts +the complete fault address in the 'si_addr' field. + +For sparc64: +$ sparc64-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-sparc64 +$ ~/inst-qemu/2.9.0/bin/qemu-sparc64 testsigsegv-sparc64 +Segmentation fault (core dumped) + + + + + + + + + + + + + +The behaviour in qemu-2.10 is the same as in qemu-2.9. + +This is an interesting collection of different bugs: + * s390x is missing masking operations, as you describe + * ppc is passing the PC of the offending insn, not the data address, into si_addr + * sparc fails to record the address of a data fault and so passes 0 into si_addr + * sparc also isn't implementing rt_sigaction correctly and so the calls in your test program fail EINVAL (your test program doesn't check the return value from sigaction, so it ploughs ahead and makes the faulting data access with the SIG_DFL behaviour for SEGV, hence the uncaught SEGV). + +I'm putting together some patches for these. + + +...and also + * SPARC doesn't implement setup_rt_frame(), so it can't deliver RT signals at all. +That's a bigger missing feature than the rest. + + +Patchset that fixes all the minor parts of this, leaving (probably) just sparc setup_rt_frame/rt_sigreturn: +https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg00833.html + + +I confirm that in qemu-2.11, the ppc and s390x cases are fixed, however the sparc64 case is still failing: + +$ ~/inst-qemu/2.11.0/bin/qemu-ppc testsigsegv-ppc +$ echo $? +0 + +$ ~/inst-qemu/2.11.0/bin/qemu-ppc64 testsigsegv-ppc64 +$ echo $? +0 + +$ ~/inst-qemu/2.11.0/bin/qemu-ppc64le testsigsegv-ppc64le +$ echo $? +0 + +$ ~/inst-qemu/2.11.0/bin/qemu-s390x testsigsegv-s390x +$ echo $? +0 +$ ~/inst-qemu/2.11.0/bin/qemu-s390x testsigsegv-s390x-a +$ echo $? +3 + +$ ~/inst-qemu/2.11.0/bin/qemu-sparc64 testsigsegv-sparc64 +setup_rt_frame: not implemented +Segmentation fault (core dumped) + + +I don't suppose anybody's going to get round to implementing RT signals for SPARC any time soon, so let's retitle this bug to track the one remaining issue. + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +The situation in version 6.0.0 is the same as in version 2.11.0: The cases ppc, ppc64, ppc64le, s390x are fixed, but the sparc64 executable still crashes. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/311 + + diff --git a/results/classifier/108/other/1705717 b/results/classifier/108/other/1705717 new file mode 100644 index 00000000..675f4a96 --- /dev/null +++ b/results/classifier/108/other/1705717 @@ -0,0 +1,78 @@ +vnc: 0.718 +PID: 0.601 +graphic: 0.593 +files: 0.589 +KVM: 0.583 +network: 0.574 +semantic: 0.567 +device: 0.558 +performance: 0.539 +other: 0.529 +permissions: 0.529 +debug: 0.523 +socket: 0.508 +boot: 0.411 + +Live migration fails with 'host' cpu when KVM is inserted with nested=1 + +Qemu v2.9.0 +Linux kernel 4.9.34 + +Live migration(pre-copy) being done from one physical host to another: + +Source Qemu: +sudo qemu-system-x86_64 -drive file=${IMAGE_DIR}/${IMAGE_NAME},if=virtio -m 2048 -smp 1 -net nic,model=virtio,macaddr=${MAC} -net tap,ifname=qtap0,script=no,downscript=no -vnc :1 --enable-kvm -cpu kvm64 -qmp tcp:*:4242,server,nowait + +And KVM is inserted with nested=1 on both source and destination machine. + +Migration fails with a nested specific assertion failure on destination at target/i386/kvm.c +1629 + +Migration is successful in the following cases- + +A) cpu model is 'host' and kvm is inserted without nested=1 parameter +B) If instead of 'host' cpu model, 'kvm64' is used (KVM nested=1) +C) If instead of 'host' cpu model, 'kvm64' is used (KVM nested=0) +D) Between an L0 and a guest Hypervisor L1, with 'kvm64' as CPU type (and nested=1 for L0 KVM) + +Physical host(s)- +$ lscpu +Architecture: x86_64 +CPU op-mode(s): 32-bit, 64-bit +Byte Order: Little Endian +CPU(s): 12 +On-line CPU(s) list: 0-11 +Thread(s) per core: 1 +Core(s) per socket: 6 +Socket(s): 2 +NUMA node(s): 2 +Vendor ID: GenuineIntel +CPU family: 6 +Model: 62 +Model name: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz +Stepping: 4 +CPU MHz: 1200.091 +CPU max MHz: 2600.0000 +CPU min MHz: 1200.0000 +BogoMIPS: 4203.28 +Virtualization: VT-x +L1d cache: 32K +L1i cache: 32K +L2 cache: 256K +L3 cache: 15360K +NUMA node0 CPU(s): 0-5 +NUMA node1 CPU(s): 6-11 +Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts + +Hi, + Can you please give the exact assertion failure. + +However, I'm confused - I think you're saying that your setup is that both hosts have nested enabled, but this is a migration of top level VM - correct? Does the top level VM have a guest inside it - migration with a nested guest is known not to work, however migration of a VM on a host with nested enabled should work if the guest doesn't use the nest. + + +Hello, +I could not replicate this behavior on another system. +So, please close this bug. +Apologies for the inconvenience. + +Hmm OK; but if you do hit it again please just reopen this one and give the full assert and details + |