On Thu, 17 Feb 2022 04:52:10 +0000, Oliver Upton <oupton@xxxxxxxxxx> wrote: > > Hi Reiji, > > First off, thanks for looking into this! Seems like a very useful thing > to test :-) > > On Wed, Feb 16, 2022 at 07:49:47PM -0800, Reiji Watanabe wrote: > > Introduce a simple performance test of KVM_GET_ONE_REG/KVM_SET_ONE_REG > > for registers that are returned by KVM_GET_REG_LIST. This is a pseudo > > process of saving/restoring registers during live migration, and this > > test quantifies the performance of the process. > > > > Signed-off-by: Reiji Watanabe <reijiw@xxxxxxxxxx> > > --- > > tools/testing/selftests/kvm/.gitignore | 1 + > > tools/testing/selftests/kvm/Makefile | 1 + > > .../selftests/kvm/aarch64/get_set_regs_perf.c | 456 ++++++++++++++++++ > [...] > Would it make sense to test some opt-in capabilities that expose > additional registers (PMU, SVE, etc.)? I think this is important. System registers are usually saved/restored in groups, and due to the way we walk the sysreg array, timings are unlikely to be uniform. Getting a grip on that could help restructure the walking if required (either per-group arrays, or maybe a tree structure). Note that all of this could equally apply to the guest trapping (the walk is the same). And yes, there are a lot of commonalities with get-reg-list, so reusing some of the existing infrastructure would be a good thing. M. -- Without deviation from the norm, progress is not possible.
