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
next prev parent 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).