From: Igor Mammedov <imammedo@redhat.com>
To: Andrew Jones <drjones@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Salil Mehta <salil.mehta@huawei.com>,
"mst@redhat.com" <mst@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Auger Eric <eric.auger@redhat.com>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>
Subject: Re: [Question] Regarding PMU initialization within the QEMU for ARM VCPUs
Date: Fri, 5 Jun 2020 17:24:05 +0200 [thread overview]
Message-ID: <20200605172405.1626979b@redhat.com> (raw)
In-Reply-To: <20200603102116.hbo4kmaitvh2kofl@kamzik.brq.redhat.com>
On Wed, 3 Jun 2020 12:21:16 +0200
Andrew Jones <drjones@redhat.com> wrote:
> On Wed, Jun 03, 2020 at 11:59:23AM +0200, Auger Eric wrote:
> > Hi Drew,
> >
> > On 6/3/20 11:37 AM, Andrew Jones wrote:
> > > On Mon, Jun 01, 2020 at 03:04:33PM +0000, Salil Mehta wrote:
> > >> Hello,
> > >> I could see below within function fdt_add_pmu_nodes() part of
> > >> hw/arm/virt.c during virt machine initialization time:
> > >>
> > >> Observation:
> > >> In below function, support of PMU feature is being checked for
> > >> each vcpu and if the PMU is found part of the features then PMU
> > >> is initialized with in the host/KVM. But if there is even one
> > >> vcpu which is found to not support the PMU then loop is exited
> > >> and PMU is not initialized for the rest of the vcpus as well.
> > >>
> > >> Questions:
> > >> Q1. Not sure what is the logic of the premature exit and not
> > >> continuing with further checks and initialization of other
> > >> VCPU PMUs?
> > >
> > > KVM requires all VCPUs to have a PMU if one does.
> >
> > I fail to find where this is enforced? Do you know the place?
>
> kvm_vcpu_set_target(), called from KVM_ARM_VCPU_INIT. It ensures
> all VCPUs have identical features selected. The PMU requires a
> VCPU feature (KVM_ARM_VCPU_PMU_V3) to be set.
perhaps add a check at cpu_preplug time to ensure that it's so before cpu is create
instead of much later FDT initialization?
>
> Thanks,
> drew
next prev parent reply other threads:[~2020-06-05 15:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 15:04 [Question] Regarding PMU initialization within the QEMU for ARM VCPUs Salil Mehta
2020-06-03 9:37 ` Andrew Jones
2020-06-03 9:59 ` Auger Eric
2020-06-03 10:21 ` Andrew Jones
2020-06-03 11:39 ` Auger Eric
2020-06-05 15:24 ` Igor Mammedov [this message]
2020-06-03 11:50 ` Salil Mehta
2020-06-03 11:45 ` Salil Mehta
2020-06-03 12:16 ` Andrew Jones
2020-06-03 13:48 ` Salil Mehta
2020-06-03 14:36 ` Andrew Jones
2020-06-03 14:53 ` Salil Mehta
2020-06-05 15:31 ` Igor Mammedov
2020-06-05 16:38 ` Salil Mehta
2020-06-08 12:00 ` Igor Mammedov
2020-06-08 13:49 ` Salil Mehta
-- strict thread matches above, loose matches on Subject: below --
2020-06-03 8:38 Salil Mehta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200605172405.1626979b@redhat.com \
--to=imammedo@redhat.com \
--cc=drjones@redhat.com \
--cc=eric.auger@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=salil.mehta@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.