All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Pierre Morel <pmorel@linux.ibm.com>, qemu-s390x@nongnu.org
Cc: qemu-devel@nongnu.org, borntraeger@de.ibm.com,
	pasic@linux.ibm.com, richard.henderson@linaro.org,
	david@redhat.com, cohuck@redhat.com, mst@redhat.com,
	pbonzini@redhat.com, kvm@vger.kernel.org, ehabkost@redhat.com,
	marcel.apfelbaum@gmail.com, eblake@redhat.com, armbru@redhat.com,
	seiden@linux.ibm.com, nrb@linux.ibm.com, scgl@linux.ibm.com,
	frankja@linux.ibm.com, berrange@redhat.com, clg@kaod.org
Subject: Re: [PATCH v13 0/7] s390x: CPU Topology
Date: Mon, 12 Dec 2022 11:17:21 +0100	[thread overview]
Message-ID: <73238c6c-a9dc-9d18-8ffb-92c8a41922d3@redhat.com> (raw)
In-Reply-To: <90514038-f10c-33e7-3600-e3131138a44d@linux.ibm.com>

On 12/12/2022 11.10, Pierre Morel wrote:
> 
> 
> On 12/12/22 10:07, Thomas Huth wrote:
>> On 12/12/2022 09.51, Pierre Morel wrote:
>>>
>>>
>>> On 12/9/22 14:32, Thomas Huth wrote:
>>>> On 08/12/2022 10.44, Pierre Morel wrote:
>>>>> Hi,
>>>>>
>>>>> Implementation discussions
>>>>> ==========================
>>>>>
>>>>> CPU models
>>>>> ----------
>>>>>
>>>>> Since the S390_FEAT_CONFIGURATION_TOPOLOGY is already in the CPU model
>>>>> for old QEMU we could not activate it as usual from KVM but needed
>>>>> a KVM capability: KVM_CAP_S390_CPU_TOPOLOGY.
>>>>> Checking and enabling this capability enables
>>>>> S390_FEAT_CONFIGURATION_TOPOLOGY.
>>>>>
>>>>> Migration
>>>>> ---------
>>>>>
>>>>> Once the S390_FEAT_CONFIGURATION_TOPOLOGY is enabled in the source
>>>>> host the STFL(11) is provided to the guest.
>>>>> Since the feature is already in the CPU model of older QEMU,
>>>>> a migration from a new QEMU enabling the topology to an old QEMU
>>>>> will keep STFL(11) enabled making the guest get an exception for
>>>>> illegal operation as soon as it uses the PTF instruction.
>>>>
>>>> I now thought that it is not possible to enable "ctop" on older QEMUs 
>>>> since the don't enable the KVM capability? ... or is it still somehow 
>>>> possible? What did I miss?
>>>>
>>>>   Thomas
>>>
>>> Enabling ctop with ctop=on on old QEMU is not possible, this is right.
>>> But, if STFL(11) is enable in the source KVM by a new QEMU, I can see 
>>> that even with -ctop=off the STFL(11) is migrated to the destination.
>>
>> Is this with the "host" CPU model or another one? And did you explicitly 
>> specify "ctop=off" at the command line, or are you just using the default 
>> setting by not specifying it?
> 
> With explicit cpumodel and using ctop=off like in
> 
> sudo /usr/local/bin/qemu-system-s390x_master \
>       -m 512M \
>       -enable-kvm -smp 4,sockets=4,cores=2,maxcpus=8 \
>       -cpu z14,ctop=off \
>       -machine s390-ccw-virtio-7.2,accel=kvm \
>       ...

Ok ... that sounds like a bug somewhere in your patches or in the kernel 
code ... the guest should never see STFL bit 11 if ctop=off, should it?

  Thomas


  reply	other threads:[~2022-12-12 10:18 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-08  9:44 [PATCH v13 0/7] s390x: CPU Topology Pierre Morel
2022-12-08  9:44 ` [PATCH v13 1/7] s390x/cpu topology: Creating CPU topology device Pierre Morel
2022-12-09 13:50   ` Thomas Huth
2022-12-12  8:52     ` Pierre Morel
2022-12-09 14:51   ` Cédric Le Goater
2022-12-08  9:44 ` [PATCH v13 2/7] s390x/cpu topology: reporting the CPU topology to the guest Pierre Morel
2022-12-09 15:43   ` Cédric Le Goater
2022-12-12  9:21     ` Pierre Morel
2022-12-08  9:44 ` [PATCH v13 3/7] s390x/cpu_topology: resetting the Topology-Change-Report Pierre Morel
2022-12-08  9:44 ` [PATCH v13 4/7] s390x/cpu_topology: CPU topology migration Pierre Morel
2022-12-09 14:56   ` Cédric Le Goater
2022-12-12  9:14     ` Pierre Morel
2022-12-11 14:55   ` Pierre Morel
2022-12-13 13:26   ` Christian Borntraeger
2022-12-13 17:40     ` Pierre Morel
2022-12-08  9:44 ` [PATCH v13 5/7] s390x/cpu_topology: interception of PTF instruction Pierre Morel
2022-12-08  9:44 ` [PATCH v13 6/7] s390x/cpu_topology: activating CPU topology Pierre Morel
2022-12-08  9:44 ` [PATCH v13 7/7] docs/s390x: document s390x cpu topology Pierre Morel
2022-12-09 13:32 ` [PATCH v13 0/7] s390x: CPU Topology Thomas Huth
2022-12-12  8:51   ` Pierre Morel
2022-12-12  9:07     ` Thomas Huth
2022-12-12 10:10       ` Pierre Morel
2022-12-12 10:17         ` Thomas Huth [this message]
2022-12-13 13:41           ` Christian Borntraeger
2022-12-13 13:57             ` Janis Schoetterl-Glausch
2022-12-13 14:00               ` Christian Borntraeger
2022-12-13 17:24             ` Pierre Morel
2022-12-14 10:39               ` Thomas Huth
2022-12-09 14:45 ` Cédric Le Goater
2022-12-12 10:01   ` Pierre Morel
2022-12-13 13:50     ` Christian Borntraeger
2022-12-13 15:12       ` Christian Borntraeger
2022-12-13 15:31         ` Janis Schoetterl-Glausch
2022-12-13 17:27           ` 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=73238c6c-a9dc-9d18-8ffb-92c8a41922d3@redhat.com \
    --to=thuth@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=clg@kaod.org \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=nrb@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=pmorel@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=scgl@linux.ibm.com \
    --cc=seiden@linux.ibm.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.