On Thu, 6 Jul 2023 14:53:35 +0000 Janosch Frank <frankja@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> Reviewed-by: Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx> > --- > > 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; > } >
