On 2020-11-26 15:54, Alexandru Elisei wrote:
Hi Marc,
On 11/26/20 3:34 PM, Marc Zyngier wrote:
Hi Alex,
On 2020-11-26 15:18, Alexandru Elisei wrote:
Hi Marc,
I checked and indeed the remaining cases cover all registers that use
this accessor.
However, I'm a bit torn here. The warning that
Hi Marc,
On 11/26/20 3:34 PM, Marc Zyngier wrote:
> Hi Alex,
>
> On 2020-11-26 15:18, Alexandru Elisei wrote:
>> Hi Marc,
>>
>> I checked and indeed the remaining cases cover all registers that use
>> this accessor.
>>
>> However, I'm a bit torn here. The warning that I got when trying to run a
Hi Alex,
On 2020-11-26 15:18, Alexandru Elisei wrote:
Hi Marc,
I checked and indeed the remaining cases cover all registers that use
this accessor.
However, I'm a bit torn here. The warning that I got when trying to run
a guest
with the PMU feature flag set, but not initialized (reported at
Hi Marc,
I checked and indeed the remaining cases cover all registers that use this
accessor.
However, I'm a bit torn here. The warning that I got when trying to run a guest
with the PMU feature flag set, but not initialized (reported at [1]) was also
not
supposed to ever be reached:
static
The handling of traps in access_pmu_evcntr() has a couple of
omminous "else return false;" statements that don't make any sense:
the decoding tree coverse all the registers that trap to this handler,
and returning false implies that we change PC, which we don't.
Get rid of what is evidently dead
