Merge tag 'kvm-s390-next-5.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git...

KVM: s390: Fix for error codes

- return the proper error to userspace when a signal interrupts the
  KSM unsharing operation

diff --combined Documentation/virt/kvm/api.rst
index 158d118,2edb28b..acebf6c
--- 1/Documentation/virt/kvm/api.rst
--- 2/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@@ -1574,8 -1574,8 +1574,8 @@@ This ioctl would set vcpu's xcr to the 
    };
  
    #define KVM_CPUID_FLAG_SIGNIFCANT_INDEX             BIT(0)
 -  #define KVM_CPUID_FLAG_STATEFUL_FUNC                BIT(1)
 -  #define KVM_CPUID_FLAG_STATE_READ_NEXT              BIT(2)
 +  #define KVM_CPUID_FLAG_STATEFUL_FUNC                BIT(1) /* deprecated */
 +  #define KVM_CPUID_FLAG_STATE_READ_NEXT              BIT(2) /* deprecated */
  
    struct kvm_cpuid_entry2 {
        __u32 function;
@@@ -1626,6 -1626,13 +1626,6 @@@ emulate them efficiently. The fields i
  
          KVM_CPUID_FLAG_SIGNIFCANT_INDEX:
             if the index field is valid
 -        KVM_CPUID_FLAG_STATEFUL_FUNC:
 -           if cpuid for this function returns different values for successive
 -           invocations; there will be several entries with the same function,
 -           all with this flag set
 -        KVM_CPUID_FLAG_STATE_READ_NEXT:
 -           for KVM_CPUID_FLAG_STATEFUL_FUNC entries, set if this entry is
 -           the first entry to be read by a cpu
  
     eax, ebx, ecx, edx:
           the values returned by the cpuid instruction for
@@@ -3342,8 -3349,8 +3342,8 @@@ The member 'flags' is used for passing 
  ::
  
    #define KVM_CPUID_FLAG_SIGNIFCANT_INDEX             BIT(0)
 -  #define KVM_CPUID_FLAG_STATEFUL_FUNC                BIT(1)
 -  #define KVM_CPUID_FLAG_STATE_READ_NEXT              BIT(2)
 +  #define KVM_CPUID_FLAG_STATEFUL_FUNC                BIT(1) /* deprecated */
 +  #define KVM_CPUID_FLAG_STATE_READ_NEXT              BIT(2) /* deprecated */
  
    struct kvm_cpuid_entry2 {
        __u32 function;
@@@ -3389,6 -3396,13 +3389,6 @@@ The fields in each entry are defined a
  
          KVM_CPUID_FLAG_SIGNIFCANT_INDEX:
             if the index field is valid
 -        KVM_CPUID_FLAG_STATEFUL_FUNC:
 -           if cpuid for this function returns different values for successive
 -           invocations; there will be several entries with the same function,
 -           all with this flag set
 -        KVM_CPUID_FLAG_STATE_READ_NEXT:
 -           for KVM_CPUID_FLAG_STATEFUL_FUNC entries, set if this entry is
 -           the first entry to be read by a cpu
  
     eax, ebx, ecx, edx:
  
@@@ -4599,38 -4613,35 +4599,38 @@@ unpins the VPA pages and releases all t
  track the secure pages by hypervisor.
  
  4.122 KVM_S390_NORMAL_RESET
 +---------------------------
  
 -Capability: KVM_CAP_S390_VCPU_RESETS
 -Architectures: s390
 -Type: vcpu ioctl
 -Parameters: none
 -Returns: 0
 +:Capability: KVM_CAP_S390_VCPU_RESETS
 +:Architectures: s390
 +:Type: vcpu ioctl
 +:Parameters: none
 +:Returns: 0
  
  This ioctl resets VCPU registers and control structures according to
  the cpu reset definition in the POP (Principles Of Operation).
  
  4.123 KVM_S390_INITIAL_RESET
 +----------------------------
  
 -Capability: none
 -Architectures: s390
 -Type: vcpu ioctl
 -Parameters: none
 -Returns: 0
 +:Capability: none
 +:Architectures: s390
 +:Type: vcpu ioctl
 +:Parameters: none
 +:Returns: 0
  
  This ioctl resets VCPU registers and control structures according to
  the initial cpu reset definition in the POP. However, the cpu is not
  put into ESA mode. This reset is a superset of the normal reset.
  
  4.124 KVM_S390_CLEAR_RESET
 +--------------------------
  
 -Capability: KVM_CAP_S390_VCPU_RESETS
 -Architectures: s390
 -Type: vcpu ioctl
 -Parameters: none
 -Returns: 0
 +:Capability: KVM_CAP_S390_VCPU_RESETS
 +:Architectures: s390
 +:Type: vcpu ioctl
 +:Parameters: none
 +:Returns: 0
  
  This ioctl resets VCPU registers and control structures according to
  the clear cpu reset definition in the POP. However, the cpu is not put
@@@ -4666,6 -4677,12 +4666,12 @@@ KVM_PV_ENABL
    command has succeeded, any CPU added via hotplug will become
    protected during its creation as well.
  
+   Errors:
+ 
+   =====      =============================
+   EINTR      an unmasked signal is pending
+   =====      =============================
+ 
  KVM_PV_DISABLE
  
    Deregister the VM from the Ultravisor and reclaim the memory that
@@@ -5743,13 -5760,8 +5749,13 @@@ and injected exceptions
  :Architectures: x86, arm, arm64, mips
  :Parameters: args[0] whether feature should be enabled or not
  
 -With this capability enabled, KVM_GET_DIRTY_LOG will not automatically
 -clear and write-protect all pages that are returned as dirty.
 +Valid flags are::
 +
 +  #define KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE   (1 << 0)
 +  #define KVM_DIRTY_LOG_INITIALLY_SET           (1 << 1)
 +
 +With KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE is set, KVM_GET_DIRTY_LOG will not
 +automatically clear and write-protect all pages that are returned as dirty.
  Rather, userspace will have to do this operation separately using
  KVM_CLEAR_DIRTY_LOG.
  
@@@ -5760,19 -5772,12 +5766,19 @@@ than requiring to sync a full memslot; 
  take spinlocks for an extended period of time.  Second, in some cases a
  large amount of time can pass between a call to KVM_GET_DIRTY_LOG and
  userspace actually using the data in the page.  Pages can be modified
 -during this time, which is inefficint for both the guest and userspace:
 +during this time, which is inefficient for both the guest and userspace:
  the guest will incur a higher penalty due to write protection faults,
  while userspace can see false reports of dirty pages.  Manual reprotection
  helps reducing this time, improving guest performance and reducing the
  number of dirty log false positives.
  
 +With KVM_DIRTY_LOG_INITIALLY_SET set, all the bits of the dirty bitmap
 +will be initialized to 1 when created.  This also improves performance because
 +dirty logging can be enabled gradually in small chunks on the first call
 +to KVM_CLEAR_DIRTY_LOG.  KVM_DIRTY_LOG_INITIALLY_SET depends on
 +KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE (it is also only available on
 +x86 for now).
 +
  KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 was previously available under the name
  KVM_CAP_MANUAL_DIRTY_LOG_PROTECT, but the implementation had bugs that make
  it hard or impossible to use it correctly.  The availability of