Skip to content
  1. Mar 16, 2020
  2. Mar 15, 2020
  3. Mar 14, 2020
    • Linus Torvalds's avatar
      Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · 69a4d0ba
      Linus Torvalds authored
      Pull clk fixes from Stephen Boyd:
       "A small collection of fixes. I'll make another sweep soon to look for
        more fixes for this -rc series.
      
         - Mark device node const in of_clk_get_parent APIs to ease landing
           changes in users later
      
         - Fix flag for Qualcomm SC7180 video clocks where we thought it would
           never turn off but actually hardware takes care of it
      
         - Remove disp_cc_mdss_rscc_ahb_clk on Qualcomm SC7180 SoCs because
           this clk is always on anyway
      
         - Correct some bad dt-binding numbers for i.MX8MN SoCs"
      
      * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
        clk: imx8mn: Fix incorrect clock defines
        clk: qcom: dispcc: Remove support of disp_cc_mdss_rscc_ahb_clk
        clk: qcom: videocc: Update the clock flag for video_cc_vcodec0_core_clk
        of: clk: Make of_clk_get_parent_{count,name}() parameter const
      69a4d0ba
    • Paolo Bonzini's avatar
      018cabb6
    • Vitaly Kuznetsov's avatar
      KVM: nVMX: avoid NULL pointer dereference with incorrect EVMCS GPAs · 95fa1010
      Vitaly Kuznetsov authored
      
      
      When an EVMCS enabled L1 guest on KVM will tries doing enlightened VMEnter
      with EVMCS GPA = 0 the host crashes because the
      
      evmcs_gpa != vmx->nested.hv_evmcs_vmptr
      
      condition in nested_vmx_handle_enlightened_vmptrld() will evaluate to
      false (as nested.hv_evmcs_vmptr is zeroed after init). The crash will
      happen on vmx->nested.hv_evmcs pointer dereference.
      
      Another problematic EVMCS ptr value is '-1' but it only causes host crash
      after nested_release_evmcs() invocation. The problem is exactly the same as
      with '0', we mistakenly think that the EVMCS pointer hasn't changed and
      thus nested.hv_evmcs_vmptr is valid.
      
      Resolve the issue by adding an additional !vmx->nested.hv_evmcs
      check to nested_vmx_handle_enlightened_vmptrld(), this way we will
      always be trying kvm_vcpu_map() when nested.hv_evmcs is NULL
      and this is supposed to catch all invalid EVMCS GPAs.
      
      Also, initialize hv_evmcs_vmptr to '0' in nested_release_evmcs()
      to be consistent with initialization where we don't currently
      set hv_evmcs_vmptr to '-1'.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      95fa1010
    • Paolo Bonzini's avatar
      Merge tag 'kvm-s390-master-5.6-1' of... · 997224fe
      Paolo Bonzini authored
      Merge tag 'kvm-s390-master-5.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master
      
      KVM: s390: Fully do the CPU resets as intended
      
      With 7de3f142 ("KVM: s390: Add new reset vcpu API") we clarified
      the meaning of the reset ioctl to fully reset the CPU and not only the
      parts that can not be handled by userspace. Turns out that we missed
      some parts.
      997224fe
    • Marc Zyngier's avatar
      irqchip/gic-v3: Workaround Cavium erratum 38539 when reading GICD_TYPER2 · d01fd161
      Marc Zyngier authored
      
      
      Despite the architecture spec requiring that reserved registers in the GIC
      distributor memory map are RES0 (and thus are not allowed to generate
      an exception), the Cavium ThunderX (aka TX1) SoC explodes as such:
      
      [    0.000000] GICv3: GIC: Using split EOI/Deactivate mode
      [    0.000000] GICv3: 128 SPIs implemented
      [    0.000000] GICv3: 0 Extended SPIs implemented
      [    0.000000] Internal error: synchronous external abort: 96000210 [#1] SMP
      [    0.000000] Modules linked in:
      [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc4-00035-g3cf6a3d5725f #7956
      [    0.000000] Hardware name: cavium,thunder-88xx (DT)
      [    0.000000] pstate: 60000085 (nZCv daIf -PAN -UAO)
      [    0.000000] pc : __raw_readl+0x0/0x8
      [    0.000000] lr : gic_init_bases+0x110/0x560
      [    0.000000] sp : ffff800011243d90
      [    0.000000] x29: ffff800011243d90 x28: 0000000000000000
      [    0.000000] x27: 0000000000000018 x26: 0000000000000002
      [    0.000000] x25: ffff8000116f0000 x24: ffff000fbe6a2c80
      [    0.000000] x23: 0000000000000000 x22: ffff010fdc322b68
      [    0.000000] x21: ffff800010a7a208 x20: 00000000009b0404
      [    0.000000] x19: ffff80001124dad0 x18: 0000000000000010
      [    0.000000] x17: 000000004d8d492b x16: 00000000f67eb9af
      [    0.000000] x15: ffffffffffffffff x14: ffff800011249908
      [    0.000000] x13: ffff800091243ae7 x12: ffff800011243af4
      [    0.000000] x11: ffff80001126e000 x10: ffff800011243a70
      [    0.000000] x9 : 00000000ffffffd0 x8 : ffff80001069c828
      [    0.000000] x7 : 0000000000000059 x6 : ffff8000113fb4d1
      [    0.000000] x5 : 0000000000000001 x4 : 0000000000000000
      [    0.000000] x3 : 0000000000000000 x2 : 0000000000000000
      [    0.000000] x1 : 0000000000000000 x0 : ffff8000116f000c
      [    0.000000] Call trace:
      [    0.000000]  __raw_readl+0x0/0x8
      [    0.000000]  gic_of_init+0x188/0x224
      [    0.000000]  of_irq_init+0x200/0x3cc
      [    0.000000]  irqchip_init+0x1c/0x40
      [    0.000000]  init_IRQ+0x160/0x1d0
      [    0.000000]  start_kernel+0x2ec/0x4b8
      [    0.000000] Code: a8c47bfd d65f03c0 d538d080 d65f03c0 (b9400000)
      
      when reading the GICv4.1 GICD_TYPER2 register, which is unexpected...
      
      Work around it by adding a new quirk for the following variants:
      
       ThunderX: CN88xx
       OCTEON TX: CN83xx, CN81xx
       OCTEON TX2: CN93xx, CN96xx, CN98xx, CNF95xx*
      
      and use this flag to avoid accessing GICD_TYPER2. Note that all
      reserved registers (including redistributors and ITS) are impacted
      by this erratum, but that only GICD_TYPER2 has to be worked around
      so far.
      
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Tested-by: default avatarRobert Richter <rrichter@marvell.com>
      Tested-by: default avatarMark Salter <msalter@redhat.com>
      Tested-by: default avatarTim Harvey <tharvey@gateworks.com>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarRobert Richter <rrichter@marvell.com>
      Link: https://lore.kernel.org/r/20191027144234.8395-11-maz@kernel.org
      Link: https://lore.kernel.org/r/20200311115649.26060-1-maz@kernel.org
      d01fd161
    • Nitesh Narayan Lal's avatar
      KVM: x86: Initializing all kvm_lapic_irq fields in ioapic_write_indirect · 0c22056f
      Nitesh Narayan Lal authored
      
      
      Previously all fields of structure kvm_lapic_irq were not initialized
      before it was passed to kvm_bitmap_or_dest_vcpus(). Which will cause
      an issue when any of those fields are used for processing a request.
      For example not initializing the msi_redir_hint field before passing
      to the kvm_bitmap_or_dest_vcpus(), may lead to a misbehavior of
      kvm_apic_map_get_dest_lapic(). This will specifically happen when the
      kvm_lowest_prio_delivery() returns TRUE due to a non-zero garbage
      value of msi_redir_hint, which should not happen as the request belongs
      to APIC fixed delivery mode and we do not want to deliver the
      interrupt only to the lowest priority candidate.
      
      This patch initializes all the fields of kvm_lapic_irq based on the
      values of ioapic redirect_entry object before passing it on to
      kvm_bitmap_or_dest_vcpus().
      
      Fixes: 7ee30bc1 ("KVM: x86: deliver KVM IOAPIC scan request to target vCPUs")
      Signed-off-by: default avatarNitesh Narayan Lal <nitesh@redhat.com>
      Reviewed-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      [Set level to false since the value doesn't really matter. Suggested
       by Vitaly Kuznetsov. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      0c22056f
    • Sean Christopherson's avatar
      KVM: VMX: Condition ENCLS-exiting enabling on CPU support for SGX1 · 7a57c09b
      Sean Christopherson authored
      
      
      Enable ENCLS-exiting (and thus set vmcs.ENCLS_EXITING_BITMAP) only if
      the CPU supports SGX1.  Per Intel's SDM, all ENCLS leafs #UD if SGX1
      is not supported[*], i.e. intercepting ENCLS to inject a #UD is
      unnecessary.
      
      Avoiding ENCLS-exiting even when it is reported as supported by the CPU
      works around a reported issue where SGX is "hard" disabled after an S3
      suspend/resume cycle, i.e. CPUID.0x7.SGX=0 and the VMCS field/control
      are enumerated as unsupported.  While the root cause of the S3 issue is
      unknown, it's definitely _not_ a KVM (or kernel) bug, i.e. this is a
      workaround for what is most likely a hardware or firmware issue.  As a
      bonus side effect, KVM saves a VMWRITE when first preparing vmcs01 and
      vmcs02.
      
      Note, SGX must be disabled in BIOS to take advantage of this workaround
      
      [*] The additional ENCLS CPUID check on SGX1 exists so that SGX can be
          globally "soft" disabled post-reset, e.g. if #MC bits in MCi_CTL are
          cleared.  Soft disabled meaning disabling SGX without clearing the
          primary CPUID bit (in leaf 0x7) and without poking into non-SGX
          CPU paths, e.g. for the VMCS controls.
      
      Fixes: 0b665d30 ("KVM: vmx: Inject #UD for SGX ENCLS instruction in guest")
      Reported-by: default avatarToni Spets <toni.spets@iki.fi>
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      7a57c09b
    • Suravee Suthikulpanit's avatar
      iommu/amd: Fix IOMMU AVIC not properly update the is_run bit in IRTE · 730ad0ed
      Suravee Suthikulpanit authored
      
      
      Commit b9c6ff94 ("iommu/amd: Re-factor guest virtual APIC
      (de-)activation code") accidentally left out the ir_data pointer when
      calling modity_irte_ga(), which causes the function amd_iommu_update_ga()
      to return prematurely due to struct amd_ir_data.ref is NULL and
      the "is_run" bit of IRTE does not get updated properly.
      
      This results in bad I/O performance since IOMMU AVIC always generate GA Log
      entry and notify IOMMU driver and KVM when it receives interrupt from the
      PCI pass-through device instead of directly inject interrupt to the vCPU.
      
      Fixes by passing ir_data when calling modify_irte_ga() as done previously.
      
      Fixes: b9c6ff94 ("iommu/amd: Re-factor guest virtual APIC (de-)activation code")
      Signed-off-by: default avatarSuravee Suthikulpanit <suravee.suthikulpanit@amd.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      730ad0ed
    • Daniel Drake's avatar
      iommu/vt-d: Ignore devices with out-of-spec domain number · da72a379
      Daniel Drake authored
      
      
      VMD subdevices are created with a PCI domain ID of 0x10000 or
      higher.
      
      These subdevices are also handled like all other PCI devices by
      dmar_pci_bus_notifier().
      
      However, when dmar_alloc_pci_notify_info() take records of such devices,
      it will truncate the domain ID to a u16 value (in info->seg).
      The device at (e.g.) 10000:00:02.0 is then treated by the DMAR code as if
      it is 0000:00:02.0.
      
      In the unlucky event that a real device also exists at 0000:00:02.0 and
      also has a device-specific entry in the DMAR table,
      dmar_insert_dev_scope() will crash on:
         BUG_ON(i >= devices_cnt);
      
      That's basically a sanity check that only one PCI device matches a
      single DMAR entry; in this case we seem to have two matching devices.
      
      Fix this by ignoring devices that have a domain number higher than
      what can be looked up in the DMAR table.
      
      This problem was carefully diagnosed by Jian-Hong Pan.
      
      Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: default avatarDaniel Drake <drake@endlessm.com>
      Fixes: 59ce0515 ("iommu/vt-d: Update DRHD/RMRR/ATSR device scope caches when PCI hotplug happens")
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      da72a379
    • Zhenzhong Duan's avatar
      iommu/vt-d: Fix the wrong printing in RHSA parsing · b0bb0c22
      Zhenzhong Duan authored
      
      
      When base address in RHSA structure doesn't match base address in
      each DRHD structure, the base address in last DRHD is printed out.
      
      This doesn't make sense when there are multiple DRHD units, fix it
      by printing the buggy RHSA's base address.
      
      Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: default avatarZhenzhong Duan <zhenzhong.duan@gmail.com>
      Fixes: fd0c8894 ("intel-iommu: Set a more specific taint flag for invalid BIOS DMAR tables")
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      b0bb0c22
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · fffb08b3
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "Two small fixes, both in drivers: ipr and ufs"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: ipr: Fix softlockup when rescanning devices in petitboot
        scsi: ufs: Fix possible unclocked access to auto hibern8 timer register
      fffb08b3
    • Linus Torvalds's avatar
      Merge tag 'nfs-for-5.6-3' of git://git.linux-nfs.org/projects/anna/linux-nfs · b0ea262a
      Linus Torvalds authored
      Pull NFS client bugfixes from Anna Schumaker:
       "These are mostly fscontext fixes, but there is also one that fixes
        collisions seen in fscache:
      
         - Ensure the fs_context has the correct fs_type when mounting and
           submounting
      
         - Fix leaking of ctx->nfs_server.hostname
      
         - Add minor version to fscache key to prevent collisions"
      
      * tag 'nfs-for-5.6-3' of git://git.linux-nfs.org/projects/anna/linux-nfs:
        nfs: add minor version to nfs_server_key for fscache
        NFS: Fix leak of ctx->nfs_server.hostname
        NFS: Don't hard-code the fs_type when submounting
        NFS: Ensure the fs_context has the correct fs_type before mounting
      b0ea262a