> From: Andrew Jones [mailto:drjo...@redhat.com] > Sent: Tuesday, June 23, 2020 10:01 AM > To: Salil Mehta <salil.me...@huawei.com> > Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org; peter.mayd...@linaro.org; > sudeep.ho...@arm.com; gs...@redhat.com; m...@redhat.com; jiakern...@gmail.com; > m...@kernel.org; zhukeqian <zhukeqi...@huawei.com>; da...@redhat.com; > richard.hender...@linaro.org; Linuxarm <linux...@huawei.com>; > eric.au...@redhat.com; james.mo...@arm.com; catalin.mari...@arm.com; > imamm...@redhat.com; pbonz...@redhat.com; mehta.salil....@gmail.com; > maran.wil...@oracle.com; w...@kernel.org; wangxiongfeng (C) > <wangxiongfe...@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 <zhukeqi...@huawei.com> > > Signed-off-by: Salil Mehta <salil.me...@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
