[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZAdhnOzIcjZBWgmc@google.com>
Date: Tue, 7 Mar 2023 08:09:00 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Reiji Watanabe <reijiw@...gle.com>
Cc: Raghavendra Rao Ananta <rananta@...gle.com>,
Oliver Upton <oupton@...gle.com>,
Marc Zyngier <maz@...nel.org>,
Ricardo Koller <ricarkol@...gle.com>,
James Morse <james.morse@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Paolo Bonzini <pbonzini@...hat.com>,
Jing Zhang <jingzhangos@...gle.com>,
Colton Lewis <coltonlewis@...gle.com>,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [REPOST PATCH 10/16] selftests: KVM: aarch64: Add KVM EVTYPE
filter PMU test
RESEND is the "standard" tag, not REPOST.
On Mon, Mar 06, 2023, Reiji Watanabe wrote:
> Hi Raghu,
>
> On Tue, Feb 14, 2023 at 5:07 PM Raghavendra Rao Ananta
> <rananta@...gle.com> wrote:
> >
> > KVM doest't allow the guests to modify the filter types
> > such counting events in nonsecure/secure-EL2, EL3, and
> > so on. Validate the same by force-configuring the bits
> > in PMXEVTYPER_EL0, PMEVTYPERn_EL0, and PMCCFILTR_EL0
> > registers.
> >
> > The test extends further by trying to create an event
> > for counting only in EL2 and validates if the counter
> > is not progressing.
> >
> > Signed-off-by: Raghavendra Rao Ananta <rananta@...gle.com>
> > ---
> > +static void guest_evtype_filter_test(void)
> > +{
> > + int i;
> > + struct pmc_accessor *acc;
> > + uint64_t typer, cnt;
> > + struct arm_smccc_res res;
> > +
> > + pmu_enable();
> > +
> > + /*
> > + * KVM blocks the guests from creating events for counting in Secure/Non-Secure Hyp (EL2),
> > + * Monitor (EL3), and Multithreading configuration. It applies the mask
> > + * ARMV8_PMU_EVTYPE_MASK against guest accesses to PMXEVTYPER_EL0, PMEVTYPERn_EL0,
> > + * and PMCCFILTR_EL0 registers to prevent this. Check if KVM honors this using all possible
> > + * ways to configure the EVTYPER.
> > + */
>
> I would prefer to break long lines into multiple lines for these comments
> (or other comments in these patches), as "Linux kernel coding style"
> suggests.
+1. And on the other side of the coin, wrap the changelog closer to ~75 chars,
~54 chars is waaay too aggressive.
Powered by blists - more mailing lists