qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Pierre Morel <pmorel@linux.ibm.com>, qemu-s390x@nongnu.org
Cc: david@redhat.com, cohuck@redhat.com,
	richard.henderson@linaro.org, qemu-devel@nongnu.org,
	pasic@linux.ibm.com, borntraeger@de.ibm.com
Subject: Re: [PATCH v3 2/4] s390x: kvm: topology: interception of PTF instruction
Date: Wed, 13 Oct 2021 11:11:30 +0200	[thread overview]
Message-ID: <803cd1be-0b06-694c-82ae-d5015a34879f@redhat.com> (raw)
In-Reply-To: <80eeffd4-25cf-c2ac-e74b-c8d5301fa98a@linux.ibm.com>

On 13/10/2021 09.55, Pierre Morel wrote:
> 
> 
> On 10/13/21 09:25, Thomas Huth wrote:
>> On 16/09/2021 15.50, Pierre Morel wrote:
>>> When the host supports the CPU topology facility, the PTF
>>> instruction with function code 2 is interpreted by the SIE,
>>> provided that the userland hypervizor activates the interpretation
>>> by using the KVM_CAP_S390_CPU_TOPOLOGY KVM extension.
>>>
>>> The PTF instructions with function code 0 and 1 are intercepted
>>> and must be emulated by the userland hypervizor.
>>>
>>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
>>> ---
...
>>> diff --git a/target/s390x/kvm/kvm.c b/target/s390x/kvm/kvm.c
>>> index 5b1fdb55c4..dd036961fe 100644
>>> --- a/target/s390x/kvm/kvm.c
>>> +++ b/target/s390x/kvm/kvm.c
>>> @@ -97,6 +97,7 @@
>>>   #define PRIV_B9_EQBS                    0x9c
>>>   #define PRIV_B9_CLP                     0xa0
>>> +#define PRIV_B9_PTF                     0xa2
>>>   #define PRIV_B9_PCISTG                  0xd0
>>>   #define PRIV_B9_PCILG                   0xd2
>>>   #define PRIV_B9_RPCIT                   0xd3
>>> @@ -362,6 +363,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
>>>       kvm_vm_enable_cap(s, KVM_CAP_S390_USER_SIGP, 0);
>>>       kvm_vm_enable_cap(s, KVM_CAP_S390_VECTOR_REGISTERS, 0);
>>>       kvm_vm_enable_cap(s, KVM_CAP_S390_USER_STSI, 0);
>>> +    kvm_vm_enable_cap(s, KVM_CAP_S390_CPU_TOPOLOGY, 0);
>>
>> Should this maybe rather be done in the last patch, to avoid a state where 
>> PTF is available, but STSI 15 is not implemented yet (when bisecting 
>> through these commits later)?
>>
>>   Thomas
>>
> 
> Yes you are right, thanks.

I'm also still a little bit surprised that there is really no migration code 
involved here yet. What if a guest gets started on a system with 
KVM_CAP_S390_CPU_TOPOLOGY support and later migrated to a system without 
KVM_CAP_S390_CPU_TOPOLOGY support? Is there already some magic in place that 
rejects such a migration? If not, the guest might first learn that it could 
use the PTF instruction, but suddenly it is then not available anymore? Does 
Linux cope right with PTF becoming unavailable during runtime? But even if 
it does, I think it's likely not in the sense of the architecture if certain 
instructions might disappear during runtime? Or do I miss something?

  Thomas



  reply	other threads:[~2021-10-13  9:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16 13:50 [PATCH v3 0/4] s390x: CPU Topology Pierre Morel
2021-09-16 13:50 ` [PATCH v3 1/4] linux-headers update Pierre Morel
2021-09-16 13:50 ` [PATCH v3 2/4] s390x: kvm: topology: interception of PTF instruction Pierre Morel
2021-10-13  7:25   ` Thomas Huth
2021-10-13  7:55     ` Pierre Morel
2021-10-13  9:11       ` Thomas Huth [this message]
2021-10-14  8:09         ` Pierre Morel
2021-10-21  8:44           ` Pierre Morel
2021-11-17 13:06     ` Pierre Morel
2021-09-16 13:50 ` [PATCH v3 3/4] s390x: topology: CPU topology objects and structures Pierre Morel
2021-10-14  7:16   ` Thomas Huth
2021-10-14 12:04     ` Pierre Morel
2021-09-16 13:50 ` [PATCH v3 4/4] s390x: topology: implementating Store Topology System Information Pierre Morel
2021-10-13  8:20   ` Thomas Huth
2021-10-13  8:40     ` 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=803cd1be-0b06-694c-82ae-d5015a34879f@redhat.com \
    --to=thuth@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=pmorel@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /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).