Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1335131
| From | Jan Glauber <jan.glauber@caviumnetworks.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v3 5/5] arm64/perf: Extend event mask for ARMv8.1 |
| Date | 2016-02-16 09:20 +0100 |
| Message-ID | <r2J1w-5ec-7@gated-at.bofh.it> (permalink) |
| References | <qY9fY-4Sx-3@gated-at.bofh.it> <qY9fZ-4Sx-31@gated-at.bofh.it> <r2xD4-5Wh-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, Feb 15, 2016 at 08:04:04PM +0000, Will Deacon wrote: [...] > On Wed, Feb 03, 2016 at 06:12:00PM +0100, Jan Glauber wrote: > > + cpu_pmu->event_mask = 0xffff; /* ARMv8.1 extended events */ > > + else > > + cpu_pmu->event_mask = ARMV8_EVTYPE_EVENT; > > ... although can't we just update ARMV8_EVTYPE_EVENT to be 0xffff now? > AFAICT, that just eats into bits that used to be RES0, so we shouldn't > see any problems. That should make your patch *much* simpler! That would of course be easier, but I just can't assess the implications. Probably I'm missing something but to me it looks like the event mask is the only verification we do for the user-space selectable events. Is it safe for implementations that only support 0x3ff events to allow access to the whole 0xffff range? What memory would be accessed for non-existing events? Jan > Will
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH v3 5/5] arm64/perf: Extend event mask for ARMv8.1 Will Deacon <will.deacon@arm.com> - 2016-02-15 21:10 +0100
Re: [PATCH v3 5/5] arm64/perf: Extend event mask for ARMv8.1 Jan Glauber <jan.glauber@caviumnetworks.com> - 2016-02-16 09:20 +0100
Re: [PATCH v3 5/5] arm64/perf: Extend event mask for ARMv8.1 Will Deacon <will.deacon@arm.com> - 2016-02-16 16:20 +0100
Re: [PATCH v3 5/5] arm64/perf: Extend event mask for ARMv8.1 Jan Glauber <jan.glauber@caviumnetworks.com> - 2016-02-17 11:50 +0100
csiph-web