[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Performance Monitor and Profiling tools for ARM64
On 4/3/19 7:57 AM, Diego Alejandro Parra Guzman wrote: Hello Julien Grall Hi Diego, thank you for your replied, you have clarified many of my doubts. I have been implementing some basic functionality for the PMU : Here small description: * getpmuinfo_attr : /* @brief get PMU info, including number of Counters, and control counters */ * enable_all_pmu_counters: /* @brief Enable the cycle counter register PMCCNTR_EL0, and any implemented event counter PMEVCNTR<n>_EL0 */ * disable_all_pmu_counters /* @brief Disable the cycle counter register PMCCNTR_EL0, and any implemented event counter PMEVCNTR<n>_EL0. */ * reset_all_pmu_counters /* @brief Reset the cycle counter register PMCCNTR_EL0, and any implemented event counter PMEVCNTR<n>_EL0.*/ * enable_user_pmu_access /* @brief Enable user-modeaccess to counters.*/I think these can be used as primitives for XEN: Now I have some additional questions about XEN: * how can I include that primitives as a driver for ARM64 in XEN? The inclusion in Xen will depend on your use cases. In my previous e-mail, I described 2 uses cases: 1) A guest profiling itself 2) The hypervisor profiling the system (i.e guests and itself) Which one are you implementing? I've noticed that in linux kernel 4.14 - 4.15 $SOURCE/drivers/perf : * there is and implementation for arm_pmu which is far better than what I've implemented, is it hard to import that driver to XEN ? arm_pmu is based on the Linux Perf subsystem. So I don't think you can re-used the driver directly. Although, you could re-use some parts at your convenience. * again how can I include that primitives as a driver for ARM64 in XEN? The first step is to define your use case. Then we can discuss how we can implement PMU support in Xen. * PMU is implemented for each CPU so how to deal with that? It depends on what you are trying to achieve. If you are exposing the PMU to the guest, then it is probably sufficient to store the context in the guest vCPU state. If you need to hold state in Xen as well, then you can use a per-cpu storage (see include/xen/percpu.h). Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |