Re: [PATCH v13 01/20] ARM64: Move PMU register related defines to asm/perf_event.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 29/02/16 18:50, Shannon Zhao wrote:
> 
> 
> On 2016/2/29 21:07, Marc Zyngier wrote:
>> Shannon,
>>
>> On 25/02/16 02:02, Shannon Zhao wrote:
>>>
>>>
>>> On 2016/2/25 1:52, Will Deacon wrote:
>>>> On Wed, Feb 24, 2016 at 01:08:21PM +0800, Shannon Zhao wrote:
>>>>> From: Shannon Zhao <shannon.zhao@xxxxxxxxxx>
>>>>>
>>>>> To use the ARMv8 PMU related register defines from the KVM code, we move
>>>>> the relevant definitions to asm/perf_event.h header file and rename them
>>>>> with prefix ARMV8_PMU_.
>>>>>
>>>>> Signed-off-by: Anup Patel <anup.patel@xxxxxxxxxx>
>>>>> Signed-off-by: Shannon Zhao <shannon.zhao@xxxxxxxxxx>
>>>>> Acked-by: Marc Zyngier <marc.zyngier@xxxxxxx>
>>>>> Reviewed-by: Andrew Jones <drjones@xxxxxxxxxx>
>>>>> ---
>>>>>  arch/arm64/include/asm/perf_event.h | 35 +++++++++++++++++++
>>>>>  arch/arm64/kernel/perf_event.c      | 68 ++++++++++---------------------------
>>>>>  2 files changed, 52 insertions(+), 51 deletions(-)
>>>>
>>>> Looks fine to me, but we're going to get some truly horrible conflicts
>>>> in -next.
>>>>
>>>> I'm open to suggestions on the best way to handle this, but one way
>>>> would be:
>>>>
>>>>   1. Duplicate all the #defines privately in KVM (queue via kvm tree)
>>> This way seems not proper I think.
>>>
>>>>   2. Rebase this patch onto my perf/updates branch [1] (queue via me)
>>> While to this series, it really relies on the perf_event.h to compile
>>> and test, so maybe for KVM-ARM and KVM maintainers it's not proper.
>>>
>>>>   3. Patch at -rc1 dropping the #defines from (1) and moving to the new
>>>>      perf_event.h stuff
>>>>
>>> I vote for this way. Since the patch in [1] is small and nothing else
>>> relies on them, I think it would be simple to rebase them onto this series.
>>>
>>>> Thoughts?
>>>>
>>> Anyway, there are only 3 lines which have conflicts. I'm not sure
>>> whether we could handle this when we merge them.
>>
>> I think you're missing the point:
>>
>> - We want both the arm64 perf and KVM trees to be easy to merge
>> - The conflicts are not that simple to resolve
>> - We want these conflicts to be solved before it hits Linus' tree
>>
> Ah, sorry. I realized this later.
> 
>> With that in mind, here's what I'm suggesting we merge as a first patch:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/kvmarm/kvmarm.git/commit/?h=queue&id=2029b4b02691ec6ebba3d281068e783353d7e108
>>
>> Once this and the perf/updates branch are merged, we can add one last
>> patch reverting this hack and actually doing the renaming work (Will has
>> posted a resolution for most of the new things).
>>
>> Thoughts?
>>
> It's fine I think. (It's first time to me to face this kind of problem.
> :)). Thanks for your help.

No worries. I've taken this patch plus most of your v14 series and the
v15 patch that you posted here, and applied the whole thing on top of
kvmarm/next (having rejigged a couple of things there). I've also fixed
the definition of ARMV8_PMU_PMCR_MASK to take PMCR_EL0.LC into account.

Please give it a go. Any fix will should now come as a patch on top of
this branch.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux