From: Pierre Morel <pmorel@linux.ibm.com>
To: "Cornelia Huck" <cohuck@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>
Cc: thuth@redhat.com, ehabkost@redhat.com, david@redhat.com,
richard.henderson@linaro.org, qemu-devel@nongnu.org,
Markus Armbruster <armbru@redhat.com>,
pasic@linux.ibm.com, borntraeger@de.ibm.com,
qemu-s390x@nongnu.org, pbonzini@redhat.com, eblake@redhat.com
Subject: Re: [PATCH v1 2/9] s390x: toplogy: adding drawers and books to smp parsing
Date: Tue, 20 Jul 2021 10:46:31 +0200 [thread overview]
Message-ID: <49614371-1357-47dd-c000-c8ff6ff845b1@linux.ibm.com> (raw)
In-Reply-To: <87wnpl8kgy.fsf@redhat.com>
On 7/20/21 10:20 AM, Cornelia Huck wrote:
> On Tue, Jul 20 2021, Pierre Morel <pmorel@linux.ibm.com> wrote:
>
>> On 7/19/21 5:50 PM, Cornelia Huck wrote:
>>> On Fri, Jul 16 2021, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>> Is the book/drawer thing architecture specific, or is it machine
>>>> type / CPU specific. ie do /all/ the s390x machine types / CPUS
>>>> QEMU support the book/drawer concept, or only a subset.
>>>
>>> Should not be by machine type, but might be by cpu model (e.g. older
>>> hardware lacking the needed support for exposing this to the guest.) IBM
>>> folks, please correct me if I'm wrong.
>>
>>
>> Looks correct to me this is an information indicated by a facility
>> introduced with Z10 if I do not make an error.
>
> Hm. Would that become a problem if we made availability of parameters
> dependent upon a value in the machine (see the other thread I cc:ed you
> on?)
>
Why?
The parameter can always be there, it is just that with older cpu model
we will not report the topology information to the guest.
The discussion on dies and on smp_dies_supported in this thread will be
interesting to follow because in my opinion dies for X or books/drawers
for Z are to be treated equally.
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
next prev parent reply other threads:[~2021-07-20 8:47 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-14 16:53 [PATCH v1 0/9] s390x: CPU Topology Pierre Morel
2021-07-14 16:53 ` [PATCH v1 1/9] s390x: smp: s390x dedicated smp parsing Pierre Morel
2021-07-16 8:54 ` Cornelia Huck
2021-07-16 9:14 ` Daniel P. Berrangé
2021-07-16 10:59 ` Pierre Morel
[not found] ` <e4865ad6-f8ec-e7ba-66ef-9c95334ba9b3@linux.ibm.com>
2021-07-19 15:43 ` Cornelia Huck
2021-07-19 15:52 ` Daniel P. Berrangé
2021-07-20 7:37 ` Pierre Morel
2021-07-20 8:33 ` Pierre Morel
2021-07-16 10:47 ` Pierre Morel
2021-07-14 16:53 ` [PATCH v1 2/9] s390x: toplogy: adding drawers and books to " Pierre Morel
2021-07-15 6:16 ` Markus Armbruster
2021-07-15 8:19 ` Pierre Morel
2021-07-15 10:48 ` Markus Armbruster
2021-07-16 9:10 ` Cornelia Huck
2021-07-16 9:18 ` Daniel P. Berrangé
2021-07-16 10:44 ` Cornelia Huck
2021-07-16 10:49 ` Daniel P. Berrangé
2021-07-19 15:50 ` Cornelia Huck
2021-07-20 7:52 ` Pierre Morel
2021-07-20 8:20 ` Cornelia Huck
2021-07-20 8:46 ` Pierre Morel [this message]
2021-07-20 9:00 ` Cornelia Huck
2021-07-20 9:19 ` Daniel P. Berrangé
2021-07-20 12:29 ` Pierre Morel
2021-07-16 9:23 ` Daniel P. Berrangé
2021-07-16 11:08 ` Pierre Morel
2021-07-14 16:53 ` [PATCH v1 3/9] s390x: cpu topology: CPU topology objects and structures Pierre Morel
2021-07-14 16:53 ` [PATCH v1 4/9] s390x: Topology list entries and SYSIB 15.x.x Pierre Morel
2021-07-14 16:53 ` [PATCH v1 5/9] s390x: topology: implementating Store Topology System Information Pierre Morel
2021-07-14 16:53 ` [PATCH v1 6/9] s390x: kvm: topology: interception of PTF instruction Pierre Morel
2021-07-16 9:22 ` Cornelia Huck
2021-07-16 11:23 ` Pierre Morel
2021-07-16 11:56 ` Cornelia Huck
2021-07-14 16:53 ` [PATCH v1 7/9] s390x: SCLP: reporting the maximum nested topology entries Pierre Morel
2021-07-16 9:24 ` Cornelia Huck
2021-07-16 11:12 ` Pierre Morel
2021-07-14 16:53 ` [PATCH v1 8/9] s390x: numa: define drawers and books for NUMA Pierre Morel
2021-07-14 16:53 ` [PATCH v1 9/9] s390x: numa: implement NUMA for S390x Pierre Morel
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=49614371-1357-47dd-c000-c8ff6ff845b1@linux.ibm.com \
--to=pmorel@linux.ibm.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=eblake@redhat.com \
--cc=ehabkost@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.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).