From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9561EC47094 for ; Thu, 10 Jun 2021 17:29:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7F355601FD for ; Thu, 10 Jun 2021 17:29:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230444AbhFJRbF (ORCPT ); Thu, 10 Jun 2021 13:31:05 -0400 Received: from mail-lf1-f45.google.com ([209.85.167.45]:37814 "EHLO mail-lf1-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230356AbhFJRbF (ORCPT ); Thu, 10 Jun 2021 13:31:05 -0400 Received: by mail-lf1-f45.google.com with SMTP id p7so4469314lfg.4 for ; Thu, 10 Jun 2021 10:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FLnQvFD4x7DNDj+NEJ3O+AkctP1r/V6a1b3Mdx886HU=; b=rYFqapPgHlrCQ4YV5UAaF9vTXxJW71bDJszf6XXAAypmGGRdGy7rfe1/NkQ88jkidv zj0sX27ZlwVd1QclSX13XE640t7tzrvWWWb1G2tctffoctIf1fhooZ7Z71CevX/0YxEF tuOvnyEYg0UtYKXQV9KQGDQGVcEUJKGE2o7Ere77VbhsmdIPiI7RPZHMj8zFUV6O58ia ZHRxLj73Uxg2A+dJQSroGT/BW6I99RPB91M1y0pZsGyl/MLduTCcimMeMfbZQU+j52PK 73cqjjeLjcblTMTYG4JtB0oQ0j/azuNLDIYH6CGSA+Lzz/w3wgp0j+picMdZdSjO0idh bqlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FLnQvFD4x7DNDj+NEJ3O+AkctP1r/V6a1b3Mdx886HU=; b=fDSKV0xIF7QKkKyNT1UvPABudKOKJXLu/EIUan4z1TI8DDb6VA5+Z+TbcIQVIhTRKr HSJcyZJJZJRrjh+ve8qAUYaE9/biAzfQZMIEwPbMcd4nHmzgOUAqLtECCsL3rNfAUpIc cjdRHEJnPg/t38+WaDNfDSF2CXR3a5ausgcoGTxWHIny5J0WrA6SWaDwVCYmDzQZAQfR hqiY9++EOcILSgbHh9m+7QLBUlwKisqe3xeHdONQYvGTgP+imIvKbYizO6xPwPYYmcbV xg66tld5AHj7bWkSqS0aVlUxYL7w1jB1aAOuX8XalXSEpcALwkKWVFbvuQldWKMpDMsR bAZQ== X-Gm-Message-State: AOAM531TUJQdkk4gV8rLxcNLZeBE8cC2f/c5keQD12MXccDXMbaFGtCe QaFCF232TvrbkP+57yTHbnnSwpEEemUpqvAL8SVpNg== X-Google-Smtp-Source: ABdhPJxMYyFCrOdc3qDmqDYkOsRd9Ou7KT5iYSlyqMweabXy+tFPPqYLyS4hzfuDF71PLN1Lon73E77keupLBsrNlto= X-Received: by 2002:a05:6512:33c4:: with SMTP id d4mr2754345lfg.536.1623346073785; Thu, 10 Jun 2021 10:27:53 -0700 (PDT) MIME-Version: 1.0 References: <20210603211426.790093-1-jingzhangos@google.com> <20210603211426.790093-3-jingzhangos@google.com> <345170fd-636c-f1be-7dc3-69467e51d872@redhat.com> In-Reply-To: <345170fd-636c-f1be-7dc3-69467e51d872@redhat.com> From: Jing Zhang Date: Thu, 10 Jun 2021 12:27:41 -0500 Message-ID: Subject: Re: [PATCH v7 2/4] KVM: stats: Add fd-based API to read binary stats data To: Paolo Bonzini Cc: KVM , KVMARM , LinuxMIPS , KVMPPC , LinuxS390 , Linuxkselftest , Marc Zyngier , James Morse , Julien Thierry , Suzuki K Poulose , Will Deacon , Huacai Chen , Aleksandar Markovic , Thomas Bogendoerfer , Paul Mackerras , Christian Borntraeger , Janosch Frank , David Hildenbrand , Cornelia Huck , Claudio Imbrenda , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Peter Shier , Oliver Upton , David Rientjes , Emanuele Giuseppe Esposito , David Matlack , Ricardo Koller , Krish Sadhukhan Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Paolo, On Thu, Jun 10, 2021 at 11:42 AM Paolo Bonzini wrote: > > On 03/06/21 23:14, Jing Zhang wrote: > > +struct _kvm_stats_header { > > + __u32 name_size; > > + __u32 count; > > + __u32 desc_offset; > > + __u32 data_offset; > > +}; > > + > > Keeping this struct in sync with kvm_stats_header is a bit messy. If > you move the id at the end of the header, however, you can use the same > trick with the zero-sized array that you used for _kvm_stats_desc. > Good point. Will do. > > +struct kvm_vm_stats_data { > > + unsigned long value[0]; > > +}; > > + > > I posted the patch to switch the VM statistics to 64-bit; you can rebase > on top of it. Cool! > > > +#define KVM_GET_STATS_FD _IOR(KVMIO, 0xcc, struct kvm_stats_header) > > This should be _IO(KVMIO, 0xcc) since it does not have an argument. > Will correct it. > > +#define STATS_DESC(stat, type, unit, scale, exp) \ > > + { \ > > + { \ > > + .flags = type | unit | scale, \ > > + .exponent = exp, \ > > + .size = 1 \ > > + }, \ > > + .name = stat, \ > > Here you can use > > type | BUILD_BUG_ON_ZERO(type & ~KVM_STATS_TYPE_MASK) | > unit | BUILD_BUG_ON_ZERO(unit & ~KVM_STATS_UNIT_MASK) | > scale | BUILD_BUG_ON_ZERO(scale & ~KVM_STATS_SCALE_MASK) | > > to get a little bit of type checking. Sure, will do. > > Paolo > Thanks, Jing