| Message ID | 20230706145335.136910-1-frankja@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: s390: Don't WARN on PV validities | expand |
Am 06.07.23 um 16:53 schrieb Janosch Frank: > Validities usually indicate KVM errors and as such we want to print a > message with a high priority to alert users that a validity > occurred. With the introduction of Protected VMs it's become very easy > to trigger validities via IOCTLs if the VM is in PV mode. > > An optimal solution would be to return EINVALs to all IOCTLs that > could result in such a situation. Unfortunately there are quite a lot > of ways to trigger PV validities since the number of allowed SCB data > combinations are very limited by FW in order to provide the guest's > security. > > Let's only log those validities to the KVM sysfs log and skip the > WARN_ONCE(). This way we get a longish lasting log entry. > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > --- Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> > > int -> ext: > * Fixed range > * Extended commit message > > --- > arch/s390/kvm/intercept.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c > index 954d39adf85c..f3c1220fd1e2 100644 > --- a/arch/s390/kvm/intercept.c > +++ b/arch/s390/kvm/intercept.c > @@ -97,9 +97,15 @@ static int handle_validity(struct kvm_vcpu *vcpu) > KVM_EVENT(3, "validity intercept 0x%x for pid %u (kvm 0x%pK)", viwhy, > current->pid, vcpu->kvm); > > - /* do not warn on invalid runtime instrumentation mode */ > - WARN_ONCE(viwhy != 0x44, "kvm: unhandled validity intercept 0x%x\n", > - viwhy); > + /* > + * Do not warn on: > + * - invalid runtime instrumentation mode > + * - PV related validities since they can be triggered by userspace > + * PV validities are in the 0x2XXX range > + */ > + WARN_ONCE(viwhy != 0x44 && > + ((viwhy < 0x2000) || (viwhy >= 0x3000)), > + "kvm: unhandled validity intercept 0x%x\n", viwhy); > return -EINVAL; > } >
On Thu, 6 Jul 2023 14:53:35 +0000 Janosch Frank <frankja@linux.ibm.com> wrote: > Validities usually indicate KVM errors and as such we want to print a > message with a high priority to alert users that a validity > occurred. With the introduction of Protected VMs it's become very easy > to trigger validities via IOCTLs if the VM is in PV mode. > > An optimal solution would be to return EINVALs to all IOCTLs that > could result in such a situation. Unfortunately there are quite a lot > of ways to trigger PV validities since the number of allowed SCB data > combinations are very limited by FW in order to provide the guest's > security. > > Let's only log those validities to the KVM sysfs log and skip the > WARN_ONCE(). This way we get a longish lasting log entry. > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> > --- > > int -> ext: > * Fixed range > * Extended commit message > > --- > arch/s390/kvm/intercept.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c > index 954d39adf85c..f3c1220fd1e2 100644 > --- a/arch/s390/kvm/intercept.c > +++ b/arch/s390/kvm/intercept.c > @@ -97,9 +97,15 @@ static int handle_validity(struct kvm_vcpu *vcpu) > KVM_EVENT(3, "validity intercept 0x%x for pid %u (kvm 0x%pK)", viwhy, > current->pid, vcpu->kvm); > > - /* do not warn on invalid runtime instrumentation mode */ > - WARN_ONCE(viwhy != 0x44, "kvm: unhandled validity intercept 0x%x\n", > - viwhy); > + /* > + * Do not warn on: > + * - invalid runtime instrumentation mode > + * - PV related validities since they can be triggered by userspace > + * PV validities are in the 0x2XXX range > + */ > + WARN_ONCE(viwhy != 0x44 && > + ((viwhy < 0x2000) || (viwhy >= 0x3000)), > + "kvm: unhandled validity intercept 0x%x\n", viwhy); > return -EINVAL; > } >
diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c index 954d39adf85c..f3c1220fd1e2 100644 --- a/arch/s390/kvm/intercept.c +++ b/arch/s390/kvm/intercept.c @@ -97,9 +97,15 @@ static int handle_validity(struct kvm_vcpu *vcpu) KVM_EVENT(3, "validity intercept 0x%x for pid %u (kvm 0x%pK)", viwhy, current->pid, vcpu->kvm); - /* do not warn on invalid runtime instrumentation mode */ - WARN_ONCE(viwhy != 0x44, "kvm: unhandled validity intercept 0x%x\n", - viwhy); + /* + * Do not warn on: + * - invalid runtime instrumentation mode + * - PV related validities since they can be triggered by userspace + * PV validities are in the 0x2XXX range + */ + WARN_ONCE(viwhy != 0x44 && + ((viwhy < 0x2000) || (viwhy >= 0x3000)), + "kvm: unhandled validity intercept 0x%x\n", viwhy); return -EINVAL; }
Validities usually indicate KVM errors and as such we want to print a message with a high priority to alert users that a validity occurred. With the introduction of Protected VMs it's become very easy to trigger validities via IOCTLs if the VM is in PV mode. An optimal solution would be to return EINVALs to all IOCTLs that could result in such a situation. Unfortunately there are quite a lot of ways to trigger PV validities since the number of allowed SCB data combinations are very limited by FW in order to provide the guest's security. Let's only log those validities to the KVM sysfs log and skip the WARN_ONCE(). This way we get a longish lasting log entry. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> --- int -> ext: * Fixed range * Extended commit message --- arch/s390/kvm/intercept.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)