Message ID | 20230306190156.434452-1-dmatlack@google.com (mailing list archive) |
---|---|
Headers | show |
Series | KVM: Refactor KVM stats macros and enable custom stat names | expand |
On Mon, Mar 06, 2023, David Matlack wrote: > David Matlack (4): > KVM: Refactor stats descriptor generation macros > KVM: Refactor designated initializer macros for struct _kvm_stats_desc > KVM: Allow custom names for KVM_STAT() > KVM: x86: Drop union for pages_{4k,2m,1g} stats > > arch/arm64/kvm/guest.c | 14 +-- > arch/mips/kvm/mips.c | 54 ++++----- > arch/powerpc/kvm/book3s.c | 62 +++++----- > arch/powerpc/kvm/booke.c | 48 ++++---- > arch/riscv/kvm/vcpu.c | 16 +-- > arch/s390/kvm/kvm-s390.c | 198 ++++++++++++++++---------------- > arch/x86/include/asm/kvm_host.h | 9 +- > arch/x86/kvm/x86.c | 94 +++++++-------- > include/linux/kvm_host.h | 179 +++++++++++------------------ > 9 files changed, 314 insertions(+), 360 deletions(-) For the series, Reviewed-by: Sean Christopherson <seanjc@google.com>
On Mon, Mar 06, 2023 at 11:01:52AM -0800, David Matlack wrote: > This series refactors the KVM stats macros to reduce duplication and > adds the support for choosing custom names for stats. > > Custom name makes it possible to decouple the userspace-visible stat > names from their internal representation in C. This can allow future > commits to refactor the various stats structs without impacting > userspace tools that read KVM stats. > > This also allows stats to be stored in data structures such as arrays, > without needing unions to access specific stats. Case in point, the last > patch in this series removes the pages_{4k,2m,1g} union, which is a > useful cleanup to prepare for sharing paging code across architectures > [1]. > > And for full transparency, another motivation for this series it that at > Google we have several out-of-tree stats that use arrays. Custom name > support is something we added internally and it reduces our technical > debt to get the support merged upstream. For the series: Reviewed-by: Oliver Upton <oliver.upton@linux.dev>