Date:   Fri, 03 Feb 2023 08:08:42 +0000
From:   Conor Dooley <conor@kernel.org>
To:     linux-riscv@lists.infradead.org,
        Atish Patra <atishp@atishpatra.org>,
        Conor Dooley <conor.dooley@microchip.com>
CC:     Atish Patra <atishp@rivosinc.com>, linux-kernel@vger.kernel.org,
        Albert Ou <aou@eecs.berkeley.edu>,
        Andrew Jones <ajones@ventanamicro.com>,
        Anup Patel <anup@brainfault.org>,
        Eric Lin <eric.lin@sifive.com>, Guo Ren <guoren@kernel.org>,
        Heiko Stuebner <heiko@sntech.de>,
        kvm-riscv@lists.infradead.org, kvm@vger.kernel.org,
        Mark Rutland <mark.rutland@arm.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Will Deacon <will@kernel.org>
Subject: Re: [PATCH v4 07/14] RISC-V: KVM: Add skeleton support for perf
User-Agent: K-9 Mail for Android
In-Reply-To: <CAOnJCUKVXGXsFBUE753-HOr_CtN-5Nsq+yBQj1eT13WyU2r54g@mail.gmail.com>
References: <20230201231250.3806412-1-atishp@rivosinc.com> <20230201231250.3806412-8-atishp@rivosinc.com> <Y9ufoeZ/4obZDJz6@wendy> <CAOnJCUKVXGXsFBUE753-HOr_CtN-5Nsq+yBQj1eT13WyU2r54g@mail.gmail.com>
Message-ID: <71788DAC-4DDF-460F-B881-58729D6D437C@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On 3 February 2023 08:04:00 GMT, Atish Patra <atishp@atishpatra=2Eorg> wro=
te:
>On Thu, Feb 2, 2023 at 3:34 AM Conor Dooley <conor=2Edooley@microchip=2Ec=
om> wrote:
>>
>> On Wed, Feb 01, 2023 at 03:12:43PM -0800, Atish Patra wrote:
>> > This patch only adds barebone structure of perf implementation=2E Mos=
t of
>> > the function returns zero at this point and will be implemented
>> > fully in the future=2E
>> >
>> > Signed-off-by: Atish Patra <atishp@rivosinc=2Ecom>
>> > +/* Per virtual pmu counter data */
>> > +struct kvm_pmc {
>> > +     u8 idx;
>> > +     struct perf_event *perf_event;
>> > +     uint64_t counter_val;
>>
>> CI also complained that here, and elsewhere, you used uint64_t rather
>> than u64=2E Am I missing a reason for not using the regular types?
>>
>
>Nope=2E It was a simple oversight=2E I will fix it=2E
>Do you have a link to the CI report so that I can address them all in v5 =
?

Try:
:%s/uint64_t/u64
It was just this patch, and checkpatch --strict should show it=2E

>
>> Thanks,
>> Conor=2E
>>
>> > +     union sbi_pmu_ctr_info cinfo;
>> > +     /* Event monitoring status */
>> > +     bool started;
>
>
>