1. 21 Nov, 2022 2 commits
  2. 12 Nov, 2022 1 commit
    • Dexuan Cui's avatar
      PCI: hv: Only reuse existing IRTE allocation for Multi-MSI · c234ba80
      Dexuan Cui authored
      Jeffrey added Multi-MSI support to the pci-hyperv driver by the 4 patches:
      08e61e86 ("PCI: hv: Fix multi-MSI to allow more than one MSI vector")
      455880df ("PCI: hv: Fix hv_arch_irq_unmask() for multi-MSI")
      b4b77778 ("PCI: hv: Reuse existing IRTE allocation in compose_msi_msg()")
      a2bad844 ("PCI: hv: Fix interrupt mapping for multi-MSI")
      
      It turns out that the third patch (b4b77778) causes a performance
      regression because all the interrupts now happen on 1 physical CPU (or two
      pCPUs, if one pCPU doesn't have enough vectors). When a guest has many PCI
      devices, it may suffer from soft lockups if the workload is heavy, e.g.,
      see https://lwn.net/ml/linux-kernel/20220804025104.15673-1-decui@microsoft.com/
      
      Commit b4b77778 itself is good. The real issue is that the hypercall in
      hv_irq_unmask() -> hv_arch_irq_unmask() ->
      hv_do_hypercall(HVCALL_RETARGET_INTERRUPT...) only changes the target
      virtual CPU rather than physical CPU; with b4b77778, the pCPU is
      determined only once in hv_compose_msi_msg() where only vCPU0 is specified;
      consequently the hypervisor only uses 1 target pCPU for all the interrupts.
      
      Note: before b4b77778, the pCPU is determined twice, and when the pCPU
      is determined the second time, the vCPU in the effective affinity mask is
      used (i.e., it isn't always vCPU0), so the hypervisor chooses different
      pCPU for each interrupt.
      
      The hypercall will be fixed in future to update the pCPU as well, but
      that will take quite a while, so let's restore the old behavior in
      hv_compose_msi_msg(), i.e., don't reuse the existing IRTE allocation for
      single-MSI and MSI-X; for multi-MSI, we choose the vCPU in a round-robin
      manner for each PCI device, so the interrupts of different devices can
      happen on different pCPUs, though the interrupts of each device happen on
      some single pCPU.
      
      The hypercall fix may not be backported to all old versions of Hyper-V, so
      we want to have this guest side change forever (or at least till we're sure
      the old affected versions of Hyper-V are no longer supported).
      
      Fixes: b4b77778 ("PCI: hv: Reuse existing IRTE allocation in compose_msi_msg()")
      Co-developed-by: default avatarJeffrey Hugo <quic_jhugo@quicinc.com>
      Signed-off-by: default avatarJeffrey Hugo <quic_jhugo@quicinc.com>
      Co-developed-by: default avatarCarl Vanderlip <quic_carlv@quicinc.com>
      Signed-off-by: default avatarCarl Vanderlip <quic_carlv@quicinc.com>
      Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
      Reviewed-by: default avatarMichael Kelley <mikelley@microsoft.com>
      Link: https://lore.kernel.org/r/20221104222953.11356-1-decui@microsoft.comSigned-off-by: default avatarWei Liu <wei.liu@kernel.org>
      c234ba80
  3. 11 Nov, 2022 2 commits
    • Michael Kelley's avatar
      scsi: storvsc: Fix handling of srb_status and capacity change events · b8a5376c
      Michael Kelley authored
      Current handling of the srb_status is incorrect. Commit 52e1b3b3
      ("scsi: storvsc: Correctly handle multiple flags in srb_status")
      is based on srb_status being a set of flags, when in fact only the
      2 high order bits are flags and the remaining 6 bits are an integer
      status. Because the integer values of interest mostly look like flags,
      the code actually works when treated that way.
      
      But in the interest of correctness going forward, fix this by treating
      the low 6 bits of srb_status as an integer status code. Add handling
      for SRB_STATUS_INVALID_REQUEST, which was the original intent of commit
      52e1b3b3. Furthermore, treat the ERROR, ABORTED, and INVALID_REQUEST
      srb status codes as essentially equivalent for the cases we care about.
      There's no harm in doing so, and it isn't always clear which status code
      current or older versions of Hyper-V report for particular conditions.
      
      Treating the srb status codes as equivalent has the additional benefit
      of ensuring that capacity change events result in an immediate rescan
      so that the new size is known to Linux. Existing code checks SCSI
      sense data for capacity change events when the srb status is ABORTED.
      But capacity change events are also being observed when Hyper-V reports
      the srb status as ERROR. Without the immediate rescan, the new size
      isn't known until something else causes a rescan (such as running
      fdisk to expand a partition), and in the meantime, tools such as "lsblk"
      continue to report the old size.
      
      Fixes: 52e1b3b3 ("scsi: storvsc: Correctly handle multiple flags in srb_status")
      Reported-by: default avatarJuan Tian <juantian@microsoft.com>
      Signed-off-by: default avatarMichael Kelley <mikelley@microsoft.com>
      Link: https://lore.kernel.org/r/1668019722-1983-1-git-send-email-mikelley@microsoft.comSigned-off-by: default avatarWei Liu <wei.liu@kernel.org>
      b8a5376c
    • Vitaly Kuznetsov's avatar
      x86/hyperv: Restore VP assist page after cpu offlining/onlining · ee681541
      Vitaly Kuznetsov authored
      Commit e5d9b714 ("x86/hyperv: fix root partition faults when writing
      to VP assist page MSR") moved 'wrmsrl(HV_X64_MSR_VP_ASSIST_PAGE)' under
      'if (*hvp)' condition. This works for root partition as hv_cpu_die()
      does memunmap() and sets 'hv_vp_assist_page[cpu]' to NULL but breaks
      non-root partitions as hv_cpu_die() doesn't free 'hv_vp_assist_page[cpu]'
      for them. This causes VP assist page to remain unset after CPU
      offline/online cycle:
      
      $ rdmsr -p 24 0x40000073
        10212f001
      $ echo 0 > /sys/devices/system/cpu/cpu24/online
      $ echo 1 > /sys/devices/system/cpu/cpu24/online
      $ rdmsr -p 24 0x40000073
        0
      
      Fix the issue by always writing to HV_X64_MSR_VP_ASSIST_PAGE in
      hv_cpu_init(). Note, checking 'if (!*hvp)', for root partition is
      pointless as hv_cpu_die() always sets 'hv_vp_assist_page[cpu]' to
      NULL (and it's also NULL initially).
      
      Note: the fact that 'hv_vp_assist_page[cpu]' is reset to NULL may
      present a (potential) issue for KVM. While Hyper-V uses
      CPUHP_AP_ONLINE_DYN stage in CPU hotplug, KVM uses CPUHP_AP_KVM_STARTING
      which comes earlier in CPU teardown sequence. It is theoretically
      possible that Enlightened VMCS is still in use. It is unclear if the
      issue is real and if using KVM with Hyper-V root partition is even
      possible.
      
      While on it, drop the unneeded smp_processor_id() call from hv_cpu_init().
      
      Fixes: e5d9b714 ("x86/hyperv: fix root partition faults when writing to VP assist page MSR")
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Reviewed-by: default avatarMichael Kelley <mikelley@microsoft.com>
      Link: https://lore.kernel.org/r/20221103190601.399343-1-vkuznets@redhat.comSigned-off-by: default avatarWei Liu <wei.liu@kernel.org>
      ee681541
  4. 03 Nov, 2022 4 commits
  5. 27 Oct, 2022 2 commits
  6. 23 Oct, 2022 9 commits
  7. 22 Oct, 2022 20 commits