| 09:38 | suihkulokki> | Ke: haven't run kvm's long term on mcbin |
| 09:39 | jnettlet[m]> | Ke: is there any debug output produced when edk2 crashes? |
| 09:39 | jnettlet[m]> | it could also be the firmware crashing when edk2 initializes the connection to it. |
| 09:40 | suihkulokki> | SCP firmware? |
| 09:42 | Ke> | strictly speaking it's the kernel crashing |
| 09:43 | Ke> | I do have some logs that are not accessible right now |
| 09:44 | suihkulokki> | Ke: you are on the 18.06 branches now? |
| 09:44 | Ke> | yes |
| 09:45 | Ke> | once buster finishes boot, it seems to be moderately stable outside of the virtualization brokennes |
| 09:46 | Ke> | I think the rcu stalls started before the 18.06 update |
| 09:48 | Ke> | all the internet seems to think virtio-net in qemu is broken, so I guess I'll try other nics soon |
| 10:42 | jnettlet[m]> | Ke: I thought there was an edk2 patch pushed that fixed virtualization issues with the RCU |
| 10:45 | Ke> | host side or guest side issues? |
| 10:45 | Ke> | jnettlet[m]: which branch, I am still using marvell-armada-wip |
| 10:46 | Ke> | there are some very recent capsule branches |
| 10:52 | jnettlet[m]> | Ke: actually it was another patch I wasa thinking about. Marvell has that in their ATF codebase now |
| 10:52 | jnettlet[m]> | it had to do with 48-bit addressing. Apparently you are hitting another bug |
| 10:53 | Ke> | I have a hunch that this may have to do with qemu updates rather than any low level host component |
| 11:51 | suihkulokki> | Ke: what I use for kvm: http://paste.debian.net/1029667/ |
| 11:55 | Ke> | -net nic,model=virtio |
| 11:57 | Ke> | I guess that's legacy option according to manual |
| 11:59 | Ke> | model=virtio is not even listed in model=help |
| 11:59 | Ke> | though almost certainly it's virtio-net-pci |
| 12:00 | Ke> | in general I guess virtio-blk-pci is worse than virtio-scsi |
| 12:19 | suihkulokki> | Ke: nic,virtio is legacy, using virtio-mmio backend and slower |
| 12:19 | suihkulokki> | virtio-scsi will give you sda* will virtio-blk will give you vda* but in practice there should not be much difference |
| 12:19 | Ke> | at least you get discard and some other scsi commands and someone claimed the performance was better |
| 12:20 | Ke> | if you do thin provisioning, discard is nice to have |
| 12:21 | Ke> | though just having sda like normal systems may add value in simplifying stupid configuration schemes |
| 12:21 | suihkulokki> | that's why I mendioned it ;) |
| 12:22 | suihkulokki> | I think virtio-scsi is a temporary step and the next generation will use nvme interfave |
| 12:23 | Ke> | nvme definitely would be preferrable for vms |
| 12:24 | Ke> | though the funny thing is that there is perhaps nothing to strictly deny nvme like behaviour on traditional interfaces, but haven't verified |
| 12:25 | Ke> | as you can always make system calls from any thread |
| 12:26 | Ke> | though I guess it's on the guest side anyway |
| 12:31 | Ke> | I believe there may be a slight problem with nvme and linux page cache model, as it may force needlessly copy the data to page cache |
| 12:31 | Ke> | as long as the data remains read only and aligned, the contents of the pages is the same |
| 12:32 | Ke> | dax type access works better in that regard |
| 12:33 | Ke> | but there is obviously no well known atomicity semantics there |
| 12:37 | Ke> | mmap writing has terrible performance on linux anyway though |
| 12:37 | Ke> | or at least on btrfs |
| 17:54 | agraf> | suihkulokki: I hear you're the mbin firmware guru now ;) |
| 17:55 | agraf> | suihkulokki: do you have any up to date notes on where to take which parts? |
| 20:45 | cow_cari_cw> | Hai |
| 20:46 | cow_cari_cw> | Jai |