From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Pierre Morel <pmorel@linux.ibm.com>, linux-s390@vger.kernel.org
Cc: alex.williamson@redhat.com, cohuck@redhat.com,
schnelle@linux.ibm.com, farman@linux.ibm.com,
borntraeger@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com,
gerald.schaefer@linux.ibm.com, agordeev@linux.ibm.com,
frankja@linux.ibm.com, david@redhat.com, imbrenda@linux.ibm.com,
vneethv@linux.ibm.com, oberpar@linux.ibm.com,
freude@linux.ibm.com, thuth@redhat.com, pasic@linux.ibm.com,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 17/30] KVM: s390: mechanism to enable guest zPCI Interpretation
Date: Mon, 24 Jan 2022 10:28:15 -0500 [thread overview]
Message-ID: <7a1fa398-3304-cb30-10c0-83e12ac9e8ac@linux.ibm.com> (raw)
In-Reply-To: <7125d611-5440-09ae-429a-7a087dd77868@linux.ibm.com>
On 1/24/22 9:24 AM, Pierre Morel wrote:
>
>
> On 1/14/22 21:31, Matthew Rosato wrote:
>> The guest must have access to certain facilities in order to allow
>> interpretive execution of zPCI instructions and adapter event
>> notifications. However, there are some cases where a guest might
>> disable interpretation -- provide a mechanism via which we can defer
>> enabling the associated zPCI interpretation facilities until the guest
>> indicates it wishes to use them.
>>
>> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
>> ---
>> arch/s390/include/asm/kvm_host.h | 4 ++++
>> arch/s390/kvm/kvm-s390.c | 40 ++++++++++++++++++++++++++++++++
>> arch/s390/kvm/kvm-s390.h | 10 ++++++++
>> 3 files changed, 54 insertions(+)
>>
>> diff --git a/arch/s390/include/asm/kvm_host.h
>> b/arch/s390/include/asm/kvm_host.h
>> index 3f147b8d050b..38982c1de413 100644
>> --- a/arch/s390/include/asm/kvm_host.h
>> +++ b/arch/s390/include/asm/kvm_host.h
>> @@ -252,7 +252,10 @@ struct kvm_s390_sie_block {
>> #define ECB2_IEP 0x20
>> #define ECB2_PFMFI 0x08
>> #define ECB2_ESCA 0x04
>> +#define ECB2_ZPCI_LSI 0x02
>> __u8 ecb2; /* 0x0062 */
>> +#define ECB3_AISI 0x20
>> +#define ECB3_AISII 0x10
>> #define ECB3_DEA 0x08
>> #define ECB3_AES 0x04
>> #define ECB3_RI 0x01
>> @@ -938,6 +941,7 @@ struct kvm_arch{
>> int use_cmma;
>> int use_pfmfi;
>> int use_skf;
>> + int use_zpci_interp;
>> int user_cpu_state_ctrl;
>> int user_sigp;
>> int user_stsi;
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index ab8b56deed11..b6c32fc3b272 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -1029,6 +1029,44 @@ static int kvm_s390_vm_set_crypto(struct kvm
>> *kvm, struct kvm_device_attr *attr)
>> return 0;
>> }
>> +static void kvm_s390_vcpu_pci_setup(struct kvm_vcpu *vcpu)
>> +{
>> + /* Only set the ECB bits after guest requests zPCI interpretation */
>> + if (!vcpu->kvm->arch.use_zpci_interp)
>> + return;
>> +
>> + vcpu->arch.sie_block->ecb2 |= ECB2_ZPCI_LSI;
>> + vcpu->arch.sie_block->ecb3 |= ECB3_AISII + ECB3_AISI;
>
> As far as I understood, the interpretation is only possible if a gisa
> designation is associated with the PCI function via CLP enable.
>
This is true. Once ECB is enabled, you must have either a SHM bit on
for emulated device support or SHM bits off + a GISA designation
registered for interpretation. Otherwise, PCI instructions will fail.
> Why do we setup the SIE ECB only when the guest requests for
> interpretation and not systematically in vcpu_setup?
Once the ECB is enabled for a guest, emulated device FHs must have a SHM
bit in order to continue working properly (so do passthrough devices
that don't setup interpretation). This was not a requirement before
this series -- simply having the ECB bit off would ensure intercepts for
all devices regardless of SHM bit settings, so by doing an opt-in once
the guest indicates it will be doing interpretation we can preserve
backwards-compatibility with an initial mode where SHM bits are not
necessarily required. However once userspace indicates it understands
interpretation, we can assume it is will also use SHM bits properly.
>
> If ECB2_ZPCI_LSI, ECB3_AISII or ECB3_AISI have an effect when the gisa
> designation is not specified shouldn't we have a way to clear these bits?
>
I'm not sure that's necessary -- The idea here was for the userspace to
indicate 1) that it knows how to setup for interpreted devices and 2)
that it has a guest that wants to use at least 1 interpreted device.
Once we know that userspace understands how to manage interpreted
devices (implied by its use of these new vfio feature ioctls) I think it
should be OK to leave these bits on and expect userspace to always do
the appropriate steps (SHM bits for emulated devices / forced intercept
passthrough devices, GISA designation for interpreted devices).
next prev parent reply other threads:[~2022-01-24 15:28 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-14 20:31 [PATCH v2 00/30] KVM: s390: enable zPCI for interpretive execution Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 01/30] s390/sclp: detect the zPCI load/store interpretation facility Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 02/30] s390/sclp: detect the AISII facility Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 03/30] s390/sclp: detect the AENI facility Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 04/30] s390/sclp: detect the AISI facility Matthew Rosato
2022-01-17 7:57 ` Thomas Huth
2022-01-14 20:31 ` [PATCH v2 05/30] s390/airq: pass more TPI info to airq handlers Matthew Rosato
2022-01-17 8:27 ` Thomas Huth
2022-01-14 20:31 ` [PATCH v2 06/30] s390/airq: allow for airq structure that uses an input vector Matthew Rosato
2022-01-17 12:29 ` Claudio Imbrenda
2022-01-18 18:52 ` Matthew Rosato
2022-01-18 9:50 ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 07/30] s390/pci: externalize the SIC operation controls and routine Matthew Rosato
2022-01-17 16:19 ` Niklas Schnelle
2022-01-26 10:07 ` Claudio Imbrenda
2022-01-27 9:57 ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 08/30] s390/pci: stash associated GISA designation Matthew Rosato
2022-01-24 14:08 ` Pierre Morel
2022-01-24 15:12 ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 09/30] s390/pci: export some routines related to RPCIT processing Matthew Rosato
2022-01-18 9:51 ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 10/30] s390/pci: stash dtsm and maxstbl Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 11/30] s390/pci: add helper function to find device by handle Matthew Rosato
2022-01-18 9:53 ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 12/30] s390/pci: get SHM information from list pci Matthew Rosato
2022-01-18 10:36 ` Pierre Morel
2022-01-26 10:13 ` Claudio Imbrenda
2022-01-27 13:41 ` Pierre Morel
2022-01-27 15:14 ` Matthew Rosato
2022-01-27 10:29 ` Niklas Schnelle
2022-01-14 20:31 ` [PATCH v2 13/30] s390/pci: return status from zpci_refresh_trans Matthew Rosato
2022-01-19 18:13 ` Pierre Morel
2022-01-26 10:45 ` Claudio Imbrenda
2022-01-27 10:30 ` Niklas Schnelle
2022-01-14 20:31 ` [PATCH v2 14/30] KVM: s390: pci: add basic kvm_zdev structure Matthew Rosato
2022-01-17 16:25 ` Pierre Morel
2022-01-18 17:32 ` Pierre Morel
2022-01-18 18:39 ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 15/30] KVM: s390: pci: do initial setup for AEN interpretation Matthew Rosato
2022-01-19 18:06 ` Pierre Morel
2022-01-19 20:19 ` Matthew Rosato
2022-01-25 12:23 ` Pierre Morel
2022-01-25 14:57 ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 16/30] KVM: s390: pci: enable host forwarding of Adapter Event Notifications Matthew Rosato
2022-01-17 17:38 ` Pierre Morel
2022-01-18 17:25 ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 17/30] KVM: s390: mechanism to enable guest zPCI Interpretation Matthew Rosato
2022-01-24 14:24 ` Pierre Morel
2022-01-24 15:28 ` Matthew Rosato [this message]
2022-01-24 17:15 ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 18/30] KVM: s390: pci: provide routines for enabling/disabling interpretation Matthew Rosato
2022-01-24 14:36 ` Pierre Morel
2022-01-24 15:14 ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 19/30] KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding Matthew Rosato
2022-01-25 12:41 ` Pierre Morel
2022-01-25 15:44 ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 20/30] KVM: s390: pci: provide routines for enabling/disabling IOAT assist Matthew Rosato
2022-01-25 13:29 ` Pierre Morel
2022-01-25 14:47 ` Matthew Rosato
2022-01-26 8:30 ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 21/30] KVM: s390: pci: handle refresh of PCI translations Matthew Rosato
2022-01-19 9:29 ` Pierre Morel
2022-01-19 16:39 ` Matthew Rosato
2022-01-19 18:25 ` Pierre Morel
2022-01-19 20:02 ` Matthew Rosato
2022-01-20 9:47 ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 22/30] KVM: s390: intercept the rpcit instruction Matthew Rosato
2022-01-18 11:05 ` Pierre Morel
2022-01-18 17:27 ` Matthew Rosato
2022-01-18 17:54 ` Pierre Morel
2022-01-19 14:06 ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 23/30] vfio/pci: re-introduce CONFIG_VFIO_PCI_ZDEV Matthew Rosato
2022-01-18 17:20 ` Pierre Morel
2022-01-18 17:32 ` Matthew Rosato
2022-01-18 17:45 ` Pierre Morel
2022-01-18 18:05 ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 24/30] vfio-pci/zdev: wire up group notifier Matthew Rosato
2022-01-18 17:34 ` Pierre Morel
2022-01-18 18:37 ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 25/30] vfio-pci/zdev: wire up zPCI interpretive execution support Matthew Rosato
2022-01-25 13:01 ` Pierre Morel
2022-01-25 14:21 ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 26/30] vfio-pci/zdev: wire up zPCI adapter interrupt forwarding support Matthew Rosato
2022-01-19 17:10 ` Pierre Morel
2022-01-19 17:20 ` Matthew Rosato
2022-01-25 12:36 ` Pierre Morel
2022-01-25 14:16 ` Matthew Rosato
2022-01-26 8:24 ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 27/30] vfio-pci/zdev: wire up zPCI IOAT assist support Matthew Rosato
2022-01-19 14:03 ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 28/30] vfio-pci/zdev: add DTSM to clp group capability Matthew Rosato
2022-01-19 13:48 ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 29/30] KVM: s390: introduce CPU feature for zPCI Interpretation Matthew Rosato
2022-01-19 13:39 ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 30/30] MAINTAINERS: additional files related kvm s390 pci passthrough Matthew Rosato
2022-01-14 20:49 ` [PATCH v2 00/30] KVM: s390: enable zPCI for interpretive execution Matthew Rosato
2022-01-19 18:10 ` 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=7a1fa398-3304-cb30-10c0-83e12ac9e8ac@linux.ibm.com \
--to=mjrosato@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=farman@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=gerald.schaefer@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=oberpar@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=schnelle@linux.ibm.com \
--cc=thuth@redhat.com \
--cc=vneethv@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.