Received: by 2002:a05:6512:3d0e:0:0:0:0 with SMTP id d14csp48754lfv; Tue, 12 Apr 2022 16:48:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxFO71KGBQaC5Mo7QfGkrwCBhIDMj/gjTCWIYZBOhv6QCXWrJTHaNw42/NXf275RomtI3a3 X-Received: by 2002:a17:90a:c7c5:b0:1cb:757c:3969 with SMTP id gf5-20020a17090ac7c500b001cb757c3969mr7700250pjb.146.1649807301668; Tue, 12 Apr 2022 16:48:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649807301; cv=none; d=google.com; s=arc-20160816; b=vHkmVJwHqg+hrAeMHkUT9G6JaXvZitcc0S04rG6b9oQ6fh/xzX9L0VZi38oIm2QNe/ cCG0olMSTlUwRTuaf/d+zwek/DfM2EJGJ/a6H7kDWoRr2g+Cv+vOD6uo1V2xA27Te7PR s4QsgdxL4nJd6YhNMKIKZzvSlgQyrkaiyJA50IlSM6Qyk4uhKbsk2tiVPSCxHz9377oi Y6ItQYwEdTXRps3nEHwKT7dlU+33k7ZXYVZ9iksRL2YMjnrlf/ufFVHLF0qQOPpQJf7a S++wRn6RCf0IUPKBOyLnhPpEhUCkpHgyMRpec3leBh4pzmTfORHmjD7TPGGAu4RHhesm emKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=bUJXQhFUIN7iCsj9QS5jIjGRNk+z+TdH4UZzpSxdCm4=; b=wDGORniIM7G8BDYt5PQ04m+RoBYjW0BcCICGr5+ZFpkPY4He8ra30QLrDB+KeG5nJI fr3uC/oHCavCagGB+oOJdtFzCbGk+/iG0hDPxCyXwWvb49siLLzoo9w/3bqpH3bN5LSU 3R3heMSr1I1VDeU7hSaWhtbd3LIMa7RP8RhN+sxx7o0CTyqhK+50R5w8aAujaLBwaElU 1MU+Vd/ZLRByDj6qNVvqwwTHaQnoeqC6fiLiZW2Ha472Hy+cF5a3XwZeA9Bl6D1HVh2U +JPsJvpT6eWk0DzZfRH5AMMeDzUnrqrQ+rYCFeZ7Cb9l3wFBdNG70E+ZpA89ED3NvoEP dJ1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="RV/micvG"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id p17-20020a63fe11000000b0039956e51e13si3918305pgh.592.2022.04.12.16.48.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 16:48:21 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="RV/micvG"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9D9C4111DCB; Tue, 12 Apr 2022 14:40:43 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350341AbiDKWRm (ORCPT + 99 others); Mon, 11 Apr 2022 18:17:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350281AbiDKWRg (ORCPT ); Mon, 11 Apr 2022 18:17:36 -0400 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E26841AD8E for ; Mon, 11 Apr 2022 15:15:20 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id 15so7045661ljw.8 for ; Mon, 11 Apr 2022 15:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bUJXQhFUIN7iCsj9QS5jIjGRNk+z+TdH4UZzpSxdCm4=; b=RV/micvGsZe9mZ8Hgcs7Y5/k/VpZqPkSFY9zXkPpDEr9tcgeW8eWFBzd1f0+r4k5b2 N+Qvt9c2zBrO8T4mdohRydU1bT1n+NID9YwvUsYGWgQ1nrgNLVYNhDVxNHEXtgHSRSlp LsMVSXHAZVAPhJRV/XSulcUDl5A5GS/Jjk/eEu6w3I29s/enzaet88wKF2ziHk8j/XwB 7F2Mjjngkfe8b8q8CBwHsDxw2oGefncdNKdWSn5qBAIEqRitrYsW6uC0iyumiYkTPAF/ +bz/TnRbM8rqQZW49yUg5+zbOjGbwPwCO4kGomjTwV+hTEMAR5PeItnQ/JsKIbAbDkm6 iTQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bUJXQhFUIN7iCsj9QS5jIjGRNk+z+TdH4UZzpSxdCm4=; b=h+Hk7vDzz3PKVQRmLroOKdUmNAnkZGT8hcRXHfcDrNUAlFDnyVWJKRIuTEARVwmgzM n9WQCB4bUzURf15dUetrei+yedP7WewDz7hB66W7hNC6ETyq4ftC85Sy0NQQ70PfuVL1 2qA9wCyaK/Jnq4c7ADbXPAJkRzpxo0VvF4LZaotLy+WyIHOQdZcIqXd0rZbu1XgT8YEd JqTcnB9m7CbXwbJalbfnMWsNmkq4ekJWCjjXUNKaZWGx7A5vgex9niWi2sZWH1xdrfkI TbLf5YlDNgxfQmzWbpZHbVBh/C0IgZ3NdlImzWncyIFObmqAJk0iRwScvTH/HQ2FoKYu GGzw== X-Gm-Message-State: AOAM532OCw+OJLYnjCV90h2nPBfPKrEsBxyR0ROneK56xCg5nHo+o/6m ZgFUq5y7XoSYaaljlK8DPPdKlCxTHDK7AHRdnA5c2Q== X-Received: by 2002:a05:651c:54c:b0:249:9d06:24ef with SMTP id q12-20020a05651c054c00b002499d0624efmr21807549ljp.331.1649715318743; Mon, 11 Apr 2022 15:15:18 -0700 (PDT) MIME-Version: 1.0 References: <20220411211015.3091615-1-bgardon@google.com> <20220411211015.3091615-5-bgardon@google.com> In-Reply-To: <20220411211015.3091615-5-bgardon@google.com> From: David Matlack Date: Mon, 11 Apr 2022 15:14:52 -0700 Message-ID: Subject: Re: [PATCH v4 04/10] KVM: selftests: Read binary stat data in lib To: Ben Gardon Cc: LKML , kvm list , Paolo Bonzini , Peter Xu , Sean Christopherson , Peter Shier , David Dunn , Junaid Shahid , Jim Mattson , Mingwei Zhang , Jing Zhang Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 11, 2022 at 2:10 PM Ben Gardon wrote: > > Move the code to read the binary stats data to the KVM selftests > library. It will be re-used by other tests to check KVM behavior. > > No functional change intended. > > Signed-off-by: Ben Gardon > --- > .../selftests/kvm/include/kvm_util_base.h | 3 +++ > .../selftests/kvm/kvm_binary_stats_test.c | 20 +++++------------- > tools/testing/selftests/kvm/lib/kvm_util.c | 21 +++++++++++++++++++ > 3 files changed, 29 insertions(+), 15 deletions(-) > > diff --git a/tools/testing/selftests/kvm/include/kvm_util_base.h b/tools/testing/selftests/kvm/include/kvm_util_base.h > index c5f34551ff76..b2684cfc2cb1 100644 > --- a/tools/testing/selftests/kvm/include/kvm_util_base.h > +++ b/tools/testing/selftests/kvm/include/kvm_util_base.h > @@ -405,6 +405,9 @@ struct kvm_stats_desc *alloc_vm_stats_desc(int stats_fd, > struct kvm_stats_header *header); > void read_vm_stats_desc(int stats_fd, struct kvm_stats_header *header, > struct kvm_stats_desc *stats_desc); > +int read_stat_data(int stats_fd, struct kvm_stats_header *header, > + struct kvm_stats_desc *desc, uint64_t *data, > + ssize_t max_elements); > > uint32_t guest_get_vcpuid(void); > > diff --git a/tools/testing/selftests/kvm/kvm_binary_stats_test.c b/tools/testing/selftests/kvm/kvm_binary_stats_test.c > index e4795bad7db6..97b180249ba0 100644 > --- a/tools/testing/selftests/kvm/kvm_binary_stats_test.c > +++ b/tools/testing/selftests/kvm/kvm_binary_stats_test.c > @@ -20,6 +20,8 @@ > #include "asm/kvm.h" > #include "linux/kvm.h" > > +#define STAT_MAX_ELEMENTS 1000 > + > static void stats_test(int stats_fd) > { > ssize_t ret; > @@ -29,7 +31,7 @@ static void stats_test(int stats_fd) > struct kvm_stats_header header; > char *id; > struct kvm_stats_desc *stats_desc; > - u64 *stats_data; > + u64 stats_data[STAT_MAX_ELEMENTS]; What is the benefit of changing stats_data to a stack allocation with a fixed limit? > struct kvm_stats_desc *pdesc; > > /* Read kvm stats header */ > @@ -130,25 +132,13 @@ static void stats_test(int stats_fd) > pdesc->offset, pdesc->name); > } > > - /* Allocate memory for stats data */ > - stats_data = malloc(size_data); > - TEST_ASSERT(stats_data, "Allocate memory for stats data"); > - /* Read kvm stats data as a bulk */ > - ret = pread(stats_fd, stats_data, size_data, header.data_offset); > - TEST_ASSERT(ret == size_data, "Read KVM stats data"); > /* Read kvm stats data one by one */ > - size_data = 0; > for (i = 0; i < header.num_desc; ++i) { > pdesc = (void *)stats_desc + i * size_desc; > - ret = pread(stats_fd, stats_data, > - pdesc->size * sizeof(*stats_data), > - header.data_offset + size_data); > - TEST_ASSERT(ret == pdesc->size * sizeof(*stats_data), > - "Read data of KVM stats: %s", pdesc->name); > - size_data += pdesc->size * sizeof(*stats_data); > + read_stat_data(stats_fd, &header, pdesc, stats_data, > + ARRAY_SIZE(stats_data)); > } > > - free(stats_data); > free(stats_desc); > free(id); > } > diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c > index e3ae26fbef03..64e2085f1129 100644 > --- a/tools/testing/selftests/kvm/lib/kvm_util.c > +++ b/tools/testing/selftests/kvm/lib/kvm_util.c > @@ -2593,3 +2593,24 @@ void read_vm_stats_desc(int stats_fd, struct kvm_stats_header *header, > TEST_ASSERT(ret == stats_descs_size(header), > "Read KVM stats descriptors"); > } > + > +int read_stat_data(int stats_fd, struct kvm_stats_header *header, I would like to keep up the practice of adding docstrings to functions in kvm_util. Can you add docstring comments for this function and the other kvm_util functions introduced by this series? > + struct kvm_stats_desc *desc, uint64_t *data, > + ssize_t max_elements) > +{ > + ssize_t ret; > + > + TEST_ASSERT(desc->size <= max_elements, > + "Max data elements should be at least as large as stat data"); What is the reason for this assertion? Callers are required to read all the data elements of a given stat? > + > + ret = pread(stats_fd, data, desc->size * sizeof(*data), > + header->data_offset + desc->offset); > + > + /* ret from pread is in bytes. */ > + ret = ret / sizeof(*data); > + > + TEST_ASSERT(ret == desc->size, > + "Read data of KVM stats: %s", desc->name); Won't this assertion fail when called from kvm_binary_stats_test.c? kvm_binary_stats_test.c looks like it reads all the stat data at once, which means ret will be the total number of stat data points, and desc->size will be the number of stat data points in the first stat. > + > + return ret; > +} > -- > 2.35.1.1178.g4f1659d476-goog >