On 10/15/18 1:30 PM, Aaron Lindsay wrote:
> On Oct 15 13:19, Richard Henderson wrote:
>> On 10/15/18 12:50 PM, Richard Henderson wrote:
>>> Ok, looking at this follow-up makes more sense than the previous patch.
>>> Would
>>> it make sense to squash these two together?
>>
>> Or, rather, split int
On Oct 15 13:19, Richard Henderson wrote:
> On 10/15/18 12:50 PM, Richard Henderson wrote:
> > Ok, looking at this follow-up makes more sense than the previous patch.
> > Would
> > it make sense to squash these two together?
>
> Or, rather, split into two different patches: the first splits pmcc
On Oct 15 12:50, Richard Henderson wrote:
> On 10/10/18 1:37 PM, Aaron Lindsay wrote:
> > pmccntr_read and pmccntr_write contained duplicate code that was already
> > being handled by pmccntr_sync. Consolidate the duplicated code into two
> > functions: pmccntr_op_start and pmccntr_op_finish. Add a
On 10/15/18 12:50 PM, Richard Henderson wrote:
> Ok, looking at this follow-up makes more sense than the previous patch. Would
> it make sense to squash these two together?
Or, rather, split into two different patches: the first splits pmccntr_sync and
updates all of the existing uses, and the se
On 10/10/18 1:37 PM, Aaron Lindsay wrote:
> pmccntr_read and pmccntr_write contained duplicate code that was already
> being handled by pmccntr_sync. Consolidate the duplicated code into two
> functions: pmccntr_op_start and pmccntr_op_finish. Add a companion to
> c15_ccnt in CPUARMState so that we
pmccntr_read and pmccntr_write contained duplicate code that was already
being handled by pmccntr_sync. Consolidate the duplicated code into two
functions: pmccntr_op_start and pmccntr_op_finish. Add a companion to
c15_ccnt in CPUARMState so that we can simultaneously save both the
architectural re
