See https://github.com/ghdl/docker/blob/master/DEPRECATED.md. Some images were moved from ghdl/docker to hdl/containers.

@antonblanchard Is there anything that can be done to get this in? Thanks.

P10 VSX-32 byte instr emulation support (v5): https://lore.kernel.org/linuxppc-dev/[email protected]

DAWR dd1 workaround (v3): https://lore.kernel.org/linuxppc-dev/[email protected]

v2: https://lore.kernel.org/linuxppc-dev/[email protected]

A large cross-arch series like that will usually be handled by Andrew Morton. So when your series lands in my next he will rebase Dmitry's series on top of that and either handle the conflicts or kick Dmitry's series back for rework.

Dmitry submitted v2: https://lore.kernel.org/patchwork/cover/1344355/

How should we coordinate his series with mine ?

The Machine checkstops if any non-virtio devices are attached to the VM. This happens when the VM tries to switch to secure mode.

Handle this gracefully, by returning an error with appropriate message.

Currently it is reflecting it to the Hypervisor. Hypervisor cannot do anything with the Hcall, since it does not have access to the secure page.

Ultravisor must handle it locally and return to the SVM.

BTW: AFAICT this hcall is made only by Hash Guests. Since we do not support Hash Guests, we have not encountered this problem. However its better to handle this call gracefully, either by handling it, or returning a U_FUNCTION error code.

#!/bin/bash sleep_sec=300 normalvm="normal" securevm="vm" function stats(){ echo "" echo $2 echo "total time from virsh cpu-stats: " virsh cpu-stats $1|grep -A3 Total:|grep -v Total: echo "cpu time from virsh vcpuinfo: " virsh vcpuinfo $1|grep "CPU time:" }

if [ "virsh domstate $normalvm" == "shut off" ]; then virsh start $normalvm else echo "make sure vms are in shutoff state" exit 1 fi if [ "virsh domstate $securevm" == "shut off" ]; then virsh start $securevm else echo "make sure vms are in shutoff state" exit 1 fi sleep 10 echo "----initial stats----" stats $normalvm "normal vm" stats $securevm "secure vm" echo "" echo "Sleeping $sleep_sec seconds..." sleep $sleep_sec echo "----stats after $sleep_sec seconds----" stats $normalvm "normal vm" stats $securevm "secure vm" normalvmpid=ps -ef|grep guest=$normalvm|grep -v grep|tr -s " "|cut -d" " -f2 securevmpid=ps -ef|grep guest=$securevm|grep -v grep|tr -s " "|cut -d" " -f2 echo "" echo "PID of normal vm: $normalvmpid" echo "PID of secure vm: $securevmpid" echo "top stats" top -p $normalvmpid -p $securevmpid -d 5 -n 2 -b echo "" echo "pid stats" echo -n "$normalvmpid: " cat /proc/$normalvmpid/stat echo "" echo -n "$securevmpid: " cat /proc/$securevmpid/stat echo "" echo -n "$normalvmpid: " cat /proc/$normalvmpid/status echo "" echo -n "$securevmpid: " cat /proc/$securevmpid/status echo ""

Make sure svm guest with name "vm" and normal guest with name "normal" is defined in the PEF host and run the attached script(cputime.sh)

Note: both normal and secure guest running no workload(idle).

./cputime.sh

Domain normal started

Domain vm started

----initial stats----

normal vm total time from virsh cpu-stats: cpu_time 10.906516180 seconds user_time 0.130000000 seconds system_time 0.260000000 seconds cpu time from virsh vcpuinfo: CPU time: 10.5s

secure vm total time from virsh cpu-stats: cpu_time 10.361590632 seconds user_time 0.130000000 seconds system_time 0.170000000 seconds cpu time from virsh vcpuinfo: CPU time: 10.1s

Sleeping 300 seconds... ----stats after 300 seconds----

normal vm total time from virsh cpu-stats: cpu_time 83.495148868 seconds user_time 0.280000000 seconds system_time 0.970000000 seconds cpu time from virsh vcpuinfo: CPU time: 33.3s CPU time: 14.8s CPU time: 17.5s CPU time: 16.7s

secure vm total time from virsh cpu-stats: cpu_time 1178.105399264 seconds -------NOK user_time 0.360000000 seconds system_time 1.300000000 seconds cpu time from virsh vcpuinfo:
CPU time: 308.9s --------------------NOK CPU time: 289.3s --------------------NOK CPU time: 289.5s --------------------NOK CPU time: 289.5s --------------------NOK

PID of normal vm: 359698 PID of secure vm: 359754 top stats top - 07:58:00 up 5 days, 5:53, 5 users, load average: 257.02, 256.84, 256.53 Tasks: 2 total, 0 running, 2 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.5 us, 0.0 sy, 0.0 ni, 97.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 519438.0 total, 472028.8 free, 12083.4 used, 35325.8 buff/cache MiB Swap: 4095.9 total, 4095.9 free, 0.0 used. 503875.7 avail Mem

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND

359754 qemu 20 0 9853.5m 8.1g 21376 S 400.0 1.6 19:39.30 qemu-kvm 359698 qemu 20 0 10.7g 1.1g 21504 S 0.0 0.2 1:23.48 qemu-kvm

top - 07:58:05 up 5 days, 5:53, 5 users, load average: 257.02, 256.85, 256.53 Tasks: 2 total, 0 running, 2 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.5 us, 0.0 sy, 0.0 ni, 97.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 519438.0 total, 472024.7 free, 12087.1 used, 35326.2 buff/cache MiB Swap: 4095.9 total, 4095.9 free, 0.0 used. 503872.1 avail Mem

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND

359754 qemu 20 0 9853.5m 8.1g 21376 S 400.0 1.6 19:59.34 qemu-kvm 359698 qemu 20 0 10.7g 1.1g 21504 S 0.0 0.2 1:23.48 qemu-kvm

pid stats 359698: 359698 (qemu-kvm) S 1 359697 359697 0 -1 138412416 3553 0 0 0 8251 97 0 0 20 0 7 0 45291836 11475615744 17856 18446744073709551615 4661903360 4672923916 140736605059008 0 0 0 268444224 4096 16963 0 0 0 17 147 0 0 0 8184 0 4673012544 4674161426 4787011584 140736605123946 140736605126312 140736605126312 140736605126626 0

359754: 359754 (qemu-kvm) S 1 359753 359753 0 -1 138412416 5039 0 0 0 119804 130 0 0 20 0 7 0 45291900 10332143616 131997 18446744073709551615 5224792064 5235812620 140736770981040 0 0 0 268444224 4096 16963 0 0 0 17 112 0 0 0 119701 0 5235901248 5237050130 5773393920 140736770995583 140736770997944 140736770997944 140736770998242 0

359698: Name: qemu-kvm Umask: 0002 State: S (sleeping) Tgid: 359698 Ngid: 359698 Pid: 359698 PPid: 1 TracerPid: 0 Uid: 107 107 107 107 Gid: 107 107 107 107 FDSize: 128 Groups: 36 107 NStgid: 359698 NSpid: 359698 NSpgid: 359697 NSsid: 359697 VmPeak: 11313984 kB VmSize: 11206656 kB VmLck: 2240 kB VmPin: 0 kB VmHWM: 1143104 kB VmRSS: 1142784 kB RssAnon: 1121280 kB RssFile: 21504 kB RssShmem: 0 kB VmData: 8598656 kB VmStk: 192 kB VmExe: 10816 kB VmLib: 30336 kB VmPTE: 218 kB VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 0 THP_enabled: 1 Threads: 7 SigQ: 0/1972697 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000010002240 SigIgn: 0000000000001000 SigCgt: 0000000180004243 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 0000003fffffffff CapAmb: 0000000000000000 NoNewPrivs: 1 Seccomp: 2 Speculation_Store_Bypass: unknown Cpus_allowed: ffffffff,ffffffff,ffffffff,ffffffff,ffffffff Cpus_allowed_list: 0-159 Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000101 Mems_allowed_list: 0,8 voluntary_ctxt_switches: 22574 nonvoluntary_ctxt_switches: 4

359754: Name: qemu-kvm Umask: 0002 State: S (sleeping) Tgid: 359754 Ngid: 359754 Pid: 359754 PPid: 1 TracerPid: 0 Uid: 107 107 107 107 Gid: 107 107 107 107 FDSize: 128 Groups: 36 107 NStgid: 359754 NSpid: 359754 NSpgid: 359753 NSsid: 359753 VmPeak: 10189056 kB VmSize: 10089984 kB VmLck: 2240 kB VmPin: 0 kB VmHWM: 8448192 kB VmRSS: 8447808 kB RssAnon: 8426432 kB RssFile: 21376 kB RssShmem: 0 kB VmData: 8595072 kB VmStk: 192 kB VmExe: 10816 kB VmLib: 30336 kB VmPTE: 1119 kB VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 0 THP_enabled: 1 Threads: 7 SigQ: 0/1972697 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000010002240 SigIgn: 0000000000001000 SigCgt: 0000000180004243 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 0000003fffffffff CapAmb: 0000000000000000 NoNewPrivs: 1 Seccomp: 2 Speculation_Store_Bypass: unknown Cpus_allowed: ffffffff,ffffffff,ffffffff,ffffffff,ffffffff Cpus_allowed_list: 0-159 Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000101 Mems_allowed_list: 0,8 voluntary_ctxt_switches: 24190 nonvoluntary_ctxt_switches: 4

Domain normal destroyed

Domain vm destroyed

I triedmake prog with the Olimex -arm-usb-tiny-h adapter to an Adafruit JTAG to SWD Cable Adapter Board connected to the OrangeCrab's JTAG port. I made the following changes to the Makefile:

GHDLARGS=-gCLK_FREQUENCY=50000000
LPF=constraints/orange-crab.lpf
PACKAGE=CSFBGA285
NEXTPNR_FLAGS=--25k --freq 50
OPENOCD_JTAG_CONFIG=openocd/olimex-arm-usb-tiny-h.cfg
OPENOCD_DEVICE_CONFIG=openocd/LFE5U-25F.cfg

I got the following error:

SIR	8	TDI  (FF);
RUNTEST	IDLE	100 TCK	1.00E-02 SEC;
SIR	8	TDI  (C0);
RUNTEST	IDLE	2 TCK	1.00E-03 SEC;
			MASK (FFFFFFFF);
SIR	8	TDI  (26);
RUNTEST	IDLE	2 TCK	2.00E-01 SEC;
SIR	8	TDI  (FF);
RUNTEST	IDLE	2 TCK	1.00E-03 SEC;
SIR	8	TDI  (3C);
			MASK (00002100);
Error: tdo check error at line 14616
Error:     READ = 0x0201e00
Error:     WANT = 0x0000100
Error:     MASK = 0x0002100

Time used: 0m1s336ms 
svf file programmed failed
in procedure 'svf'
Makefile:55: recipe for target 'prog' failed
make: *** [prog] Error 1

Any thoughts?

fix https://github.com/antonblanchard/will-it-scale/issues/29 When running the context_switch1 in the thread mode test case, it has "Assertion `ret == 1' failed" error logs print for the system with a a huge number of CPU cores. The pipe fd(struct args a) init as the stack when the thread number increased to some special number, the stack data will be damaged, change it to init as the heap, then no assertion happened again.

When running the context_switch1 in the thread mode test case, it has "Assertion `ret == 1' failed" error logs print for the system with a huge number of CPU cores. The pipe fd(struct args a) init as stack when the thread number increased to some special number, the stack data will be damaged, change it to init as the heap, then no assertion happened again.

Signed-off-by: Zhengjun Xing [email protected]

This issue is to gather WIP around VDSO with aims at cleaning it up.

We have my series at https://patchwork.ozlabs.org/project/linuxppc-dev/cover/[email protected]/ This series mainly cleans up and slims down VDSO setup. Part of it is to move to using the modern _install_special_mapping().

In parallele we have the series from Dmitry at https://lore.kernel.org/patchwork/cover/1334692/ that tries to rework VDSO mapping/unmapping to get more secure unmapping that won't lead to the risk of running in the weed.

Dmitry series misses the changes to powerpc as powerpc VDSO doesn't yet have support of _install_special_mapping()

Hi, When I run the context_switch1 test case, it always has "Assertion `ret == 1' failed" error logs print. Is it a bug in the context_switch1 test case or anything I miss set in my test environment? Thanks.

./runtest.py context_switch1

tasks,processes,processes_idle,threads,threads_idle,linear 0,0,100,0,100,0 1,68256,95.36,66138,94.85,68256 2,76699,90.28,73780,89.28,136512 3,84784,85.62,81063,83.96,204768 4,88903,80.67,84356,78.38,273024 5,88330,75.48,85081,72.51,341280 6,85265,70.19,81569,66.29,409536 7,58732,64.09,55989,59.40,477792 8,47108,57.85,44998,52.48,546048 9,42748,52.49,41092,45.95,614304 10,41694,45.56,39321,38.94,682560 context_switch1_threads: tests/context_switch1.c:33: child: Assertion ret == 1' failed. Aborted (core dumped) 11,39928,39.31,-1,32.14,750816 12,39229,23.49,37818,21.88,819072 context_switch1_threads: tests/context_switch1.c:33: child: Assertionret == 1' failed. Aborted (core dumped) 13,40762,29.42,-1,21.74,887328 context_switch1_threads: tests/context_switch1.c:33: child: Assertion ret == 1' failed. context_switch1_threads: tests/context_switch1.c:33: child: Assertionret == 1' failed. Aborted (core dumped) 14,42321,27.15,-1,19.65,955584 context_switch1_threads: tests/context_switch1.c:33: child: Assertion ret == 1' failed. Aborted (core dumped) 15,43718,24.91,-1,17.53,1023840 context_switch1_threads: tests/context_switch1.c:33: child: Assertionret == 1' failed. context_switch1_threads: tests/context_switch1.c:33: child: Assertion ret == 1' failed. Aborted (core dumped) 16,45299,22.78,-1,15.62,1092096 context_switch1_threads: tests/context_switch1.c:33: child: Assertionret == 1' failed. Aborted (core dumped) 17,46794,20.72,-1,13.85,1160352 context_switch1_threads: tests/context_switch1.c:33: child: Assertion ret == 1' failed. context_switch1_threads: tests/context_switch1.c:33: child: Assertionret == 1' failed. context_switch1_threads: tests/context_switch1.c:33: child: Assertion ret == 1' failed. Aborted (core dumped) 18,48335,18.68,-1,12.17,1228608 context_switch1_threads: tests/context_switch1.c:33: child: Assertionret == 1' failed. context_switch1_threads: tests/context_switch1.c:33: child: Assertion ret == 1' failed. Aborted (core dumped) 19,50144,16.81,-1,10.37,1296864 context_switch1_threads: tests/context_switch1.c:33: child: Assertionret == 1' failed. context_switch1_threads: tests/context_switch1.c:33: child: Assertion ret == 1' failed. Aborted (core dumped) 20,51297,15.15,-1,8.61,1365120 context_switch1_threads: tests/context_switch1.c:33: child: Assertionret == 1' failed. context_switch1_threads: tests/context_switch1.c:33: child: Assertion ret == 1' failed. context_switch1_threads: tests/context_switch1.c:33: child: Assertionret == 1' failed. Aborted (core dumped) 21,52643,13.47,-1,7.00,1433376 context_switch1_threads: tests/context_switch1.c:33: child: Assertion ret == 1' failed. context_switch1_threads: tests/context_switch1.c:33: child: Assertionret == 1' failed. context_switch1_threads: tests/context_switch1.c:33: child: Assertion ret == 1' failed. Aborted (core dumped) 22,53904,11.86,-1,5.52,1501632 context_switch1_threads: tests/context_switch1.c:33: child: Assertionret == 1' failed. context_switch1_threads: tests/context_switch1.c:33: child: Assertion ret == 1' failed. context_switch1_threads: tests/context_switch1.c:33: child: Assertionret == 1' failed. Aborted (core dumped) 23,55055,10.40,-1,4.14,1569888 context_switch1_threads: tests/context_switch1.c:33: child: Assertion ret == 1' failed. context_switch1_threads: tests/context_switch1.c:33: child: Assertionret == 1' failed. Aborted (core dumped) 24,56513,9.05,-1,2.79,1638144

ulimit -a

core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 190679 max locked memory (kbytes, -l) 65536 max memory size (kbytes, -m) unlimited open files (-n) 1048576 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 1048576 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited

@antonblanchard is there something which can be done to get this in?

The following trace was provided by syzkaller:

------------[ cut here ]------------
kernel BUG at arch/powerpc/kernel/tm.S:446!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 1 PID: 31158 Comm: modprobe Not tainted 5.5.0-rc1-syzkaller-00285-g07c4b9e9f71a #0
NIP:  c00000000008f80c LR: 0000000000000000 CTR: 0000000000000000
REGS: c00000001b9876a0 TRAP: 0700   Not tainted  (5.5.0-rc1-syzkaller-00285-g07c4b9e9f71a)
MSR:  8000000102823033 <SF,VEC,VSX,FP,ME,IR,DR,RI,LE,TM[E]>  CR: 24008284  XER: 00000000
CFAR: c00000000008f550 IRQMASK: 3 
GPR00: 0000000000000000 c00000001b987930 0000000000000000 0000000000000000 
GPR04: 0000000000000000 0000000000000000 0000000000000000 c000000018ca9238 
GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
GPR12: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
GPR28: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
NIP [c00000000008f80c] restore_gprs+0xb0/0x198
LR [0000000000000000] 0x0
Call Trace:
[c00000001b987b20] [c000000000029dc8] tm_recheckpoint.part.20+0x88/0x140 arch/powerpc/kernel/process.c:945
[c00000001b987b60] [c00000000002bd24] tm_recheckpoint arch/powerpc/kernel/process.c:966 [inline]
[c00000001b987b60] [c00000000002bd24] tm_recheckpoint_new_task arch/powerpc/kernel/process.c:974 [inline]
[c00000001b987b60] [c00000000002bd24] __switch_to_tm arch/powerpc/kernel/process.c:1002 [inline]
[c00000001b987b60] [c00000000002bd24] __switch_to+0x5c4/0x6e0 arch/powerpc/kernel/process.c:1171
[c00000001b987bd0] [c0000000014c5c84] context_switch kernel/sched/core.c:3385 [inline]
[c00000001b987bd0] [c0000000014c5c84] __schedule+0x3c4/0xcc0 kernel/sched/core.c:4081
[c00000001b987ca0] [c000000000201e90] do_task_dead+0x70/0x80 kernel/sched/core.c:4098
[c00000001b987cd0] [c0000000001a0740] do_exit+0xa60/0x1230 kernel/exit.c:849
[c00000001b987db0] [c0000000001a1038] do_group_exit+0x88/0x120 kernel/exit.c:895
[c00000001b987df0] [c0000000001a1104] __do_sys_exit_group kernel/exit.c:906 [inline]
[c00000001b987df0] [c0000000001a1104] sys_exit_group+0x34/0x40 kernel/exit.c:904
[c00000001b987e20] [c00000000000bbd0] system_call+0x5c/0x68
Instruction dump:
eb470140 eb670148 eb870150 eba70158 ebc70160 ebe70168 7cb103a6 7cc0e3a6 
7ca222a6 78a58402 38c00800 7cc62838 <08860000> 7cc000a6 38a00006 78c60022 
---[ end trace f30fe688e945b34e ]---

Reference: https://syzkaller-ppc64.appspot.com/bug?id=a57abe11616ad6a33b0a9795b499ca3ff549046f

That issue was never observed or created again. After carefully checking trecheckpoint the only thing I can think of causing it is an interaction with another bug that corrupted values in the stack, but since there was not way to recreate it 's hard to confirm. I'll close that issue but few free to reopen it a similar trace is observed again.