From: Andrew Jones <drjones@redhat.com>
To: "wangyanan (Y)" <wangyanan55@huawei.com>
Cc: "Barry Song" <song.bao.hua@hisilicon.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Michael S . Tsirkin" <mst@redhat.com>,
wanghaibin.wang@huawei.com, zhukeqian1@huawei.com,
qemu-devel@nongnu.org, yangyicong@huawei.com,
"Shannon Zhao" <shannon.zhaosl@gmail.com>,
qemu-arm@nongnu.org,
"Alistair Francis" <alistair.francis@wdc.com>,
prime.zeng@hisilicon.com, "Paolo Bonzini" <pbonzini@redhat.com>,
yuzenghui@huawei.com, "Igor Mammedov" <imammedo@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: [RFC PATCH v3 6/9] hw/arm/virt-acpi-build: Use possible cpus in generation of MADT
Date: Tue, 18 May 2021 15:40:45 +0200 [thread overview]
Message-ID: <20210518134045.5enuusitvaho3xv3@gator.home> (raw)
In-Reply-To: <1a0a9dea-cd42-a2e5-6b1c-0055391d439f@huawei.com>
On Tue, May 18, 2021 at 07:47:24PM +0800, wangyanan (Y) wrote:
> > > Is there any better alternative way about this?
> > Move the
> >
> > if (arm_feature(&armcpu->env, ARM_FEATURE_PMU)) {
> > gicc->performance_interrupt = cpu_to_le32(PPI(VIRTUAL_PMU_IRQ));
> > }
> >
> > into the if (possible_cpus->cpus[i].cpu != NULL) block?
> We can. But this will only ensure that we initialize
> gicc->performance_interrupt
> for enabled GICC entries but not the disabled ones.
I'd write a comment and leave that problem for the hot plug support to
solve.
> > > Can we also update the arch_id at the same time when we change mp_affinity?
> > The proper fix is to send patches to KVM enabling userspace to control
> > MPIDR. Otherwise we can't be sure we don't have inconsistencies in QEMU,
> > since some user of possible_cpus could have made decisions or copied IDs
> > prior to KVM vcpu init time. Now, all that said, I think
> > virt_cpu_mp_affinity() should be generating the same ID as KVM does, so
> > maybe it doesn't matter in practice right now, but we're living with the
> > risk that KVM could change. For now, maybe we should just sanity check
> > that the KVM values match the possible_cpus values and emit warnings if
> > they don't?
> I think it may not so reasonable to emit warnings if they don't match, on
> the contrary we should ensure they will match even when KVM changes.
>
> Now virt_cpu_mp_affinity() is only called by virt_possible_cpu_arch_ids() to
> initialize possible_cpus, so an idea is that we can move the stuff of
> resetting
> "cpu->mp_affinity" from kvm_arch_init_vcpu() to virt_cpu_mp_affinity() to
> initialize arch_id. So that we can ensure mp_affinity only comes from
> arch_id
> and won't change later. Can it work?
No. virt_cpu_mp_affinity can run way before cpu realize, but
kvm_arch_init_vcpu runs at cpu realize time.
>
> BTW, I plan to pack patch 4-6 into a separate patchset and repost it until
> we have a mature solution for the probelm, that's also Salil's suggestion.
> Is it appropriate?
Well, you still need to set the enabled flag in the GICC table and you'll
still need to come up with a solution for user input of cpus < maxcpus,
but if your solution to the latter is good, then whatever you like.
Thanks,
drew
next prev parent reply other threads:[~2021-05-18 13:44 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-16 10:28 [RFC PATCH v3 0/9] hw/arm/virt: Introduce cpu topology support Yanan Wang
2021-05-16 10:28 ` [RFC PATCH v3 1/9] hw/arm/virt: Disable cpu topology support on older machine types Yanan Wang
2021-05-16 10:28 ` [RFC PATCH v3 2/9] device_tree: Add qemu_fdt_add_path Yanan Wang
2021-05-17 3:11 ` David Gibson
2021-05-17 13:18 ` wangyanan (Y)
2021-05-17 6:27 ` Andrew Jones
2021-05-17 13:21 ` wangyanan (Y)
2021-05-16 10:28 ` [RFC PATCH v3 3/9] hw/arm/virt: Add cpu-map to device tree Yanan Wang
2021-05-17 6:41 ` Andrew Jones
2021-05-17 15:00 ` wangyanan (Y)
2021-05-18 7:46 ` Andrew Jones
2021-05-18 10:50 ` wangyanan (Y)
2021-05-16 10:28 ` [RFC PATCH v3 4/9] hw/arm/virt: Initialize the present cpu members Yanan Wang
2021-05-17 6:43 ` Andrew Jones
2021-05-17 20:48 ` Salil Mehta
2021-05-18 4:42 ` wangyanan (Y)
2021-05-18 7:04 ` Salil Mehta
2021-05-18 7:50 ` Andrew Jones
2021-05-18 18:50 ` Salil Mehta
2021-05-16 10:28 ` [RFC PATCH v3 5/9] hw/arm/virt-acpi-build: Use possible cpus in generation of DSDT Yanan Wang
2021-05-16 10:28 ` [RFC PATCH v3 6/9] hw/arm/virt-acpi-build: Use possible cpus in generation of MADT Yanan Wang
2021-05-17 7:42 ` Andrew Jones
2021-05-17 16:27 ` wangyanan (Y)
2021-05-18 8:15 ` Andrew Jones
2021-05-18 11:47 ` wangyanan (Y)
2021-05-18 13:40 ` Andrew Jones [this message]
2021-05-17 17:07 ` Salil Mehta
2021-05-18 5:02 ` wangyanan (Y)
2021-05-18 6:47 ` Salil Mehta
2021-05-18 11:58 ` wangyanan (Y)
2021-05-16 10:28 ` [RFC PATCH v3 7/9] hw/acpi/aml-build: Add Processor hierarchy node structure Yanan Wang
2021-05-17 7:47 ` Andrew Jones
2021-05-16 10:28 ` [RFC PATCH v3 8/9] hw/arm/virt-acpi-build: Generate PPTT table Yanan Wang
2021-05-17 8:02 ` Andrew Jones
2021-05-17 13:43 ` wangyanan (Y)
2021-05-17 14:45 ` Andrew Jones
2021-05-17 16:02 ` wangyanan (Y)
2021-05-16 10:29 ` [RFC PATCH v3 9/9] hw/arm/virt: Add separate -smp parsing function for ARM machines Yanan Wang
2021-05-17 8:24 ` Andrew Jones
2021-05-18 2:16 ` wangyanan (Y)
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=20210518134045.5enuusitvaho3xv3@gator.home \
--to=drjones@redhat.com \
--cc=alistair.francis@wdc.com \
--cc=david@gibson.dropbear.id.au \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=prime.zeng@hisilicon.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shannon.zhaosl@gmail.com \
--cc=song.bao.hua@hisilicon.com \
--cc=wanghaibin.wang@huawei.com \
--cc=wangyanan55@huawei.com \
--cc=yangyicong@huawei.com \
--cc=yuzenghui@huawei.com \
--cc=zhukeqian1@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).