RE: [PATCH RFC 07/22] arm/cpuhp: Init PMU at host for all possible vcpus

[Salil Mehta]

> From: Andrew Jones [mailto:drjones@redhat.com]
> Sent: Tuesday, June 23, 2020 10:01 AM
> To: Salil Mehta <salil.mehta@huawei.com>
> Cc: qemu-devel@nongnu.org; qemu-arm@nongnu.org; peter.maydell@linaro.org;
> sudeep.holla@arm.com; gshan@redhat.com; mst@redhat.com; jiakernel2@gmail.com;
> maz@kernel.org; zhukeqian <zhukeqian1@huawei.com>; david@redhat.com;
> richard.henderson@linaro.org; Linuxarm <linuxarm@huawei.com>;
> eric.auger@redhat.com; james.morse@arm.com; catalin.marinas@arm.com;
> imammedo@redhat.com; pbonzini@redhat.com; mehta.salil.lnk@gmail.com;
> maran.wilson@oracle.com; will@kernel.org; wangxiongfeng (C)
> <wangxiongfeng2@huawei.com>
> Subject: Re: [PATCH RFC 07/22] arm/cpuhp: Init PMU at host for all possible 
> vcpus
> 
> On Sat, Jun 13, 2020 at 10:36:14PM +0100, Salil Mehta wrote:
> > PMU for all possible vcpus must be initialized at the virt machine
> > initialization time. This patch refactors existing code to accomodate 
> > possible
> > vcpus. This also assumes that all processor being used are identical at 
> > least
> > for now but does not affect the normal scanarios where they might not be in
> > future. This assumption only affects the future hotplug scenarios if ever 
> > there
> > exists any hetergenous processors. In such a case PMU might not be enabled
> on
> > some vcpus. Is it acceptable and doable tradeoff for now?
> >
> > This perhaps needs more discussion. please check below link,
> > Link: https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00131.html
> >
> > Co-developed-by: Keqian Zhu <zhukeqian1@huawei.com>
> > Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> > ---
> >  hw/arm/virt.c         | 51 ++++++++++++++++++++++++++++++-------------
> >  include/hw/arm/virt.h |  1 +
> >  2 files changed, 37 insertions(+), 15 deletions(-)
> >
> 
> I have a similar patch to this one in my steal-time dev branch that I just
> started last week. I'm creating a new function that must be called after
> cpu realization and gic creation that completes cpu setup. There's a few
> things that will end up there (including steal-time stuff).

ok. 

> 
> Thanks,
> drew