On Sat, Dec 10, 2016 at 09:47:05PM +0100, Christoffer Dall wrote: > We currently spend around ~400 cycles on each entry/exit to the guest > dealing with arch timer registers, even when the timer is not pending > and not doing anything. > > We can do much better by moving the arch timer save/restore to the > vcpu_load and vcpu_put functions, but this means that if we don't read > back the timer state on every exit from the guest, then we have to be > able to start taking timer interrupts for the virtual timer in KVM and > handle that properly. > > That has a number of funny consequences, such as having to make sure we > don't deadlock between any of the vgic code and interrupt injection > happening from an ISR. On the plus side, being able to inject > virtual interrupts corresponding to a physical interrupt directly from > an ISR is probably a good system design change. > > We also have to change the use of the physical vs. virtual counter in > the arm64 kernel to avoid having to save/restore the CNTVOFF_EL2 > register on every return to the hypervisor. The only reason I could > find for using the virtual counter for the kernel on systems with access > to the physical counter is to detect if firmware did not properly clear > CNTVOFF_EL2, and this change has to weighed against the existing check > (assuming I got this right). > > On a non-VHE system (AMD Seattle) I have measured this to improve the > world-switch time by about ~100 cycles, but on an EL2 kernel (emulating > VHE behavior on the same hardware) this gives us around ~250 cycles > worth of improvement, because we can avoid the extra configuration of > trapping accesses to the physical timer from EL1 on every switch. > > I'm not sure if the benefits outweigh the complexity of this patch set, > nor am I sure if I'm missing an overall better approach, hence the RFC > tag on the series. > > I'm looking forward to overall comments on the approach. > FYI for anyone looking at these patches, I found some issues with the series and will respin shortly. Patch 5 has also been split to hopefully simplify the review, as I realized it is horrible to look at in its current form. Thanks, -Christoffer -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
