LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Pierre Morel <pmorel@linux.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	kvm@vger.kernel.org
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
	frankja@linux.ibm.com, cohuck@redhat.com, thuth@redhat.com,
	imbrenda@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com
Subject: Re: [PATCH v3 2/3] s390x: KVM: Implementation of Multiprocessor Topology-Change-Report
Date: Wed, 8 Sep 2021 14:00:19 +0200	[thread overview]
Message-ID: <d76697e5-d7fb-4210-234a-7b3482e7babc@linux.ibm.com> (raw)
In-Reply-To: <66754109-4b35-f6e5-3db7-654d8b67392e@de.ibm.com>



On 9/8/21 9:04 AM, Christian Borntraeger wrote:
> 
> 
> On 07.09.21 12:24, Pierre Morel wrote:
>>
>>
>> On 9/6/21 8:37 PM, David Hildenbrand wrote:
>>> On 03.08.21 10:26, Pierre Morel wrote:
>>>> We let the userland hypervisor know if the machine support the CPU
>>>> topology facility using a new KVM capability: 
>>>> KVM_CAP_S390_CPU_TOPOLOGY.
>>>>
>>>> The PTF instruction will report a topology change if there is any 
>>>> change
>>>> with a previous STSI_15_2 SYSIB.
>>>> Changes inside a STSI_15_2 SYSIB occur if CPU bits are set or clear
>>>> inside the CPU Topology List Entry CPU mask field, which happens with
>>>> changes in CPU polarization, dedication, CPU types and adding or
>>>> removing CPUs in a socket.
>>>>
>>>> The reporting to the guest is done using the Multiprocessor
>>>> Topology-Change-Report (MTCR) bit of the utility entry of the guest's
>>>> SCA which will be cleared during the interpretation of PTF.
>>>>
>>>> To check if the topology has been modified we use a new field of the
>>>> arch vCPU to save the previous real CPU ID at the end of a schedule
>>>> and verify on next schedule that the CPU used is in the same socket.
>>>>
>>>> We deliberatly ignore:
>>>> - polarization: only horizontal polarization is currently used in 
>>>> linux.
>>>> - CPU Type: only IFL Type are supported in Linux
>>>> - Dedication: we consider that only a complete dedicated CPU stack can
>>>>    take benefit of the CPU Topology.
>>>>
>>>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
>>>
>>>
>>>> @@ -228,7 +232,7 @@ struct kvm_s390_sie_block {
>>>>       __u8    icptcode;        /* 0x0050 */
>>>>       __u8    icptstatus;        /* 0x0051 */
>>>>       __u16    ihcpu;            /* 0x0052 */
>>>> -    __u8    reserved54;        /* 0x0054 */
>>>> +    __u8    mtcr;            /* 0x0054 */
>>>>   #define IICTL_CODE_NONE         0x00
>>>>   #define IICTL_CODE_MCHK         0x01
>>>>   #define IICTL_CODE_EXT         0x02
>>>> @@ -246,6 +250,7 @@ struct kvm_s390_sie_block {
>>>>   #define ECB_TE        0x10
>>>>   #define ECB_SRSI    0x04
>>>>   #define ECB_HOSTPROTINT    0x02
>>>> +#define ECB_PTF        0x01
>>>
>>>  From below I understand, that ECB_PTF can be used with stfl(11) in 
>>> the hypervisor.
>>>
>>> What is to happen if the hypervisor doesn't support stfl(11) and we 
>>> consequently cannot use ECB_PTF? Will QEMU be able to emulate PTF fully?
>>
>> Yes.
> 
> Do we want that? I do not think so. Other OSes (like zOS) do use PTF in 
> there low level interrupt handler, so PTF must be really fast.
> I think I would prefer that in that case the guest will simply not see 
> stfle(11).
> So the user can still specify the topology but the guest will have no 
> interface to query it.

I do not understand.
If the host support stfle(11) we interpret PTF.

The proposition was to emulate only in the case it is not supported, 
what you propose is to not advertise stfl(11) if the host does not 
support it, and consequently to never emulate is it right?

In this case, as STSI_15 is linked to stfl(11) too, the guest will not 
be aware of the topology.

OK for me.

-- 
Pierre Morel
IBM Lab Boeblingen

  reply	other threads:[~2021-09-08 12:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-03  8:26 [PATCH v3 0/3] s390x: KVM: CPU Topology Pierre Morel
2021-08-03  8:26 ` [PATCH v3 1/3] s390x: KVM: accept STSI for CPU topology information Pierre Morel
2021-08-31 13:59   ` David Hildenbrand
2021-09-01  9:43     ` Pierre Morel
2021-09-06 18:14       ` David Hildenbrand
2021-09-07 10:11         ` Pierre Morel
2021-08-03  8:26 ` [PATCH v3 2/3] s390x: KVM: Implementation of Multiprocessor Topology-Change-Report Pierre Morel
2021-08-31 14:03   ` David Hildenbrand
2021-09-01  9:46     ` Pierre Morel
2021-09-06 18:37   ` David Hildenbrand
2021-09-07 10:24     ` Pierre Morel
2021-09-08  7:04       ` Christian Borntraeger
2021-09-08 12:00         ` Pierre Morel [this message]
2021-09-08 12:01           ` Christian Borntraeger
2021-09-08 12:52             ` Pierre Morel
2021-09-07 12:28     ` Pierre Morel
2021-09-08  7:07       ` Christian Borntraeger
2021-09-08 13:09         ` Pierre Morel
2021-09-08 13:16           ` Christian Borntraeger
2021-09-08 14:17             ` Pierre Morel
2021-09-09  9:03     ` Pierre Morel
2021-08-03  8:26 ` [PATCH v3 3/3] s390x: optimization of the check for CPU topology change Pierre Morel
2021-08-03  8:42   ` Heiko Carstens
2021-08-03  8:57     ` Pierre Morel
2021-08-03  9:28       ` 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=d76697e5-d7fb-4210-234a-7b3482e7babc@linux.ibm.com \
    --to=pmorel@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=thuth@redhat.com \
    --subject='Re: [PATCH v3 2/3] s390x: KVM: Implementation of Multiprocessor Topology-Change-Report' \
    /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

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).