> From: Paolo Bonzini [mailto:pbonzini@xxxxxxxxxx] > Sent: Monday, March 19, 2018 11:59 AM > > This obviously reintroduces the same issue noted in the second of these > commits: "If the guest floods this port with writes it generates > exceptions and instability in the host kernel, leading to a crash". So > this patch is not acceptable. Hi Paulo, > > What is exactly the use case where a VM is doing a lot of 0x80 accesses > at run-time? > None specifically, but it is otherwise "normal" behavior of some VMs. Apparently it used to be a common method to synchronize writes to other I/O ports. In the commit thread for the original commit no-one was able to reproduce it. There are no details on what processors are impacted or exactly what the "exceptions and instability in the host kernel" were. In terms of performance, below is a the mpstat output (from the host) for a CPU performing L2 packet forwarding on a pinned guest VCPU. Interrupts on that core are disabled. You can see it switching in and out of userspace constantly. $ mpstat -P 5 5 11:32:03 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle Average: 5 6.91 0.00 26.98 0.00 0.00 0.00 0.00 65.78 0.00 0.33 # sample trace output: CPU 1/KVM-11359 [005] d... 2207.865724: kvm_entry: vcpu 1 CPU 1/KVM-11359 [005] .... 2207.865767: kvm_exit: reason IO_INSTRUCTION rip 0x483213 info c0700001 0 CPU 1/KVM-11359 [005] .... 2207.865768: kvm_pio: pio_write at 0xc070 size 2 count 1 val 0x0 CPU 1/KVM-11359 [005] d... 2207.865769: kvm_entry: vcpu 1 CPU 1/KVM-11359 [005] .... 2207.865771: kvm_exit: reason IO_INSTRUCTION rip 0x483215 info 800040 0 CPU 1/KVM-11359 [005] .... 2207.865772: kvm_pio: pio_write at 0x80 size 1 count 1 val 0x0 CPU 1/KVM-11359 [005] .... 2207.865773: kvm_fpu: unload CPU 1/KVM-11359 [005] .... 2207.865774: kvm_userspace_exit: reason KVM_EXIT_IO (2) According to perf, 0x80 writes can take over 2ms $ perf kvm stat report --event=ioport IO Port Access Samples Samples% Time% Min Time Max Time Avg time 0x80:POUT 316206 49.99% 81.97% 9.41us 2195.77us 10.41us ( +- 0.14% ) 0xc070:POUT 158623 25.08% 9.18% 1.99us 29.27us 2.32us ( +- 0.05% ) 0xc090:POUT 157583 24.91% 8.84% 1.97us 36.90us 2.25us ( +- 0.05% ) 0x608:PIN 150 0.02% 0.02% 3.83us 6.71us 4.26us ( +- 1.01% ) 0xc010:POUT 1 0.00% 0.00% 16.19us 16.19us 16.19us ( +- 0.00% ) With the fix reverted, performance is restored (~95% guest-mode processing vs ~66%): $ mpstat -P 5 5 08:30:03 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle Average: 5 0.00 0.00 4.26 0.00 0.00 0.00 0.00 95.74 0.00 0.00 I understand that security/stability must take priority over performance. I would love to understand more about the original vulnerability though, because the performance cost is so high. Many thanks, Tim
