From: "Daniel P. Berrangé" <email@example.com>
To: "wangyanan (Y)" <firstname.lastname@example.org>
Cc: Barry Song <email@example.com>,
Peter Maydell <firstname.lastname@example.org>,
Andrew Jones <email@example.com>,
"Michael S . Tsirkin" <firstname.lastname@example.org>,
email@example.com, Shannon Zhao <firstname.lastname@example.org>,
email@example.com, Alistair Francis <firstname.lastname@example.org>,
email@example.com, Paolo Bonzini <firstname.lastname@example.org>,
email@example.com, Igor Mammedov <firstname.lastname@example.org>,
email@example.com, David Gibson <firstname.lastname@example.org>
Subject: Re: [RFC PATCH v4 0/7] hw/arm/virt: Introduce cpu topology support
Date: Tue, 22 Jun 2021 13:41:58 +0100 [thread overview]
Message-ID: <YNHalhuNZhMa665J@redhat.com> (raw)
On Tue, Jun 22, 2021 at 08:31:22PM +0800, wangyanan (Y) wrote:
> On 2021/6/22 19:46, Andrew Jones wrote:
> > On Tue, Jun 22, 2021 at 11:18:09AM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Jun 22, 2021 at 05:34:06PM +0800, Yanan Wang wrote:
> > > > Hi,
> > > >
> > > > This is v4 of the series  that I posted to introduce support for
> > > > generating cpu topology descriptions to guest. Comments are welcome!
> > > >
> > > > Description:
> > > > Once the view of an accurate virtual cpu topology is provided to guest,
> > > > with a well-designed vCPU pinning to the pCPU we may get a huge benefit,
> > > > e.g., the scheduling performance improvement. See Dario Faggioli's
> > > > research and the related performance tests in  for reference. So here
> > > > we go, this patch series introduces cpu topology support for ARM platform.
> > > >
> > > > In this series, instead of quietly enforcing the support for the latest
> > > > machine type, a new parameter "expose=on|off" in -smp command line is
> > > > introduced to leave QEMU users a choice to decide whether to enable the
> > > > feature or not. This will allow the feature to work on different machine
> > > > types and also ideally compat with already in-use -smp command lines.
> > > > Also we make much stricter requirement for the topology configuration
> > > > with "expose=on".
> > > Seeing this 'expose=on' parameter feels to me like we're adding a
> > > "make-it-work=yes" parameter. IMHO this is just something that should
> > > be done by default for the current machine type version and beyond.
> > > I don't see the need for a parameter to turnthis on, especially since
> > > it is being made architecture specific.
> > >
> > I agree.
> > Yanan, we never discussed an "expose" parameter in the previous versions
> > of this series. We discussed a "strict" parameter though, which would
> > allow existing command lines to "work" using assumptions of what the user
> > meant and strict=on users to get what they mean or an error saying that
> > they asked for something that won't work or would require unreasonable
> > assumptions. Why was this changed to an "expose" parameter?
> Yes, we indeed discuss a new "strict" parameter but not a "expose" in v2 
> of this series.
>  https://email@example.com/
> And in the discussion, we hoped things would work like below with "strict"
> Users who want to describe cpu topology should provide cmdline like
> -smp strict=on,cpus=4,sockets=2,cores=2,threads=1
> and in this case we require an more accurate -smp configuration and
> then generate the cpu topology description through ACPI/DT.
> While without a strict description, no cpu topology description would
> be generated, so they get nothing through ACPI/DT.
> It seems to me that the "strict" parameter actually serves as a knob to
> turn on/off the exposure of topology, and this is the reason I changed
> the name.
Yes, the use of 'strict=on' is no better than expose=on IMHO.
If I give QEMU a cli
then I expect that topology to be exposed to the guest. I shouldn't
have to add extra flags to make that happen.
Looking at the thread, it seems the concern was around the fact that
the settings were not honoured historically and thus the CLI values
could be garbage. ie -smp cpus=4,sockets=8,cores=3,thread=9
A similar problem existed on x86 platforms. When we made that stricter
we had cde that issued a warning for a few releases, essentially
deprecating the config. EVentually it was turned into a fatal error.
This gave applications time to fix their broken configs, while having
correct configs "just work".
I'd suggest doing the same for arm. If the -smp args are semantically
valid then expose the topology automatically (for new machine type).
If the -smp args are semantically broken, then issue a warning. In
a few releases time, turn this warning into an error.
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2021-06-22 12:45 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-22 9:34 [RFC PATCH v4 0/7] hw/arm/virt: Introduce cpu topology support Yanan Wang
2021-06-22 9:34 ` [RFC PATCH v4 1/7] vl: Add expose=on|off option support in -smp command line Yanan Wang
2021-06-22 9:34 ` [RFC PATCH v4 2/7] hw/arm/virt: Add separate -smp parsing function for ARM machines Yanan Wang
2021-06-22 9:34 ` [RFC PATCH v4 3/7] machine: disallow -smp expose=on for non-ARM machines Yanan Wang
2021-06-22 9:34 ` [RFC PATCH v4 4/7] device_tree: Add qemu_fdt_add_path Yanan Wang
2021-06-22 9:34 ` [RFC PATCH v4 5/7] hw/arm/virt: Add cpu-map to device tree Yanan Wang
2021-06-22 9:34 ` [RFC PATCH v4 6/7] hw/acpi/aml-build: Add Processor hierarchy node structure Yanan Wang
2021-06-22 9:34 ` [RFC PATCH v4 7/7] hw/acpi/aml-build: Generate PPTT table Yanan Wang
2021-06-22 10:18 ` [RFC PATCH v4 0/7] hw/arm/virt: Introduce cpu topology support Daniel P. Berrangé
2021-06-22 11:46 ` Andrew Jones
2021-06-22 12:31 ` wangyanan (Y)
2021-06-22 12:41 ` Daniel P. Berrangé [this message]
2021-06-22 14:04 ` wangyanan (Y)
2021-06-22 14:10 ` Daniel P. Berrangé
2021-06-22 14:15 ` Peter Maydell
2021-06-22 14:28 ` Daniel P. Berrangé
2021-06-28 11:14 ` wangyanan (Y)
2021-06-28 11:31 ` Daniel P. Berrangé
2021-06-28 11:53 ` wangyanan (Y)
2021-06-22 14:29 ` Andrew Jones
2021-06-22 15:15 ` Daniel P. Berrangé
2021-06-22 15:40 ` Igor Mammedov
2021-06-22 17:08 ` Andrew Jones
2021-06-22 17:14 ` Daniel P. Berrangé
2021-06-22 17:29 ` Andrew Jones
2021-06-22 17:39 ` Daniel P. Berrangé
2021-06-28 8:43 ` wangyanan (Y)
2021-06-28 8:58 ` Andrew Jones
2021-06-28 10:48 ` wangyanan (Y)
2021-06-30 6:36 ` wangyanan (Y)
2021-06-30 8:30 ` Andrew Jones
2021-06-30 9:37 ` wangyanan (Y)
2021-06-30 11:56 ` Andrew Jones
2021-07-01 6:15 ` wangyanan (Y)
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).