1. 11 1月, 2021 1 次提交
  2. 10 1月, 2021 1 次提交
    • C
      bcache: introduce BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE for large bucket · b16671e8
      Coly Li 提交于
      When large bucket feature was added, BCH_FEATURE_INCOMPAT_LARGE_BUCKET
      was introduced into the incompat feature set. It used bucket_size_hi
      (which was added at the tail of struct cache_sb_disk) to extend current
      16bit bucket size to 32bit with existing bucket_size in struct
      cache_sb_disk.
      
      This is not a good idea, there are two obvious problems,
      - Bucket size is always value power of 2, if store log2(bucket size) in
        existing bucket_size of struct cache_sb_disk, it is unnecessary to add
        bucket_size_hi.
      - Macro csum_set() assumes d[SB_JOURNAL_BUCKETS] is the last member in
        struct cache_sb_disk, bucket_size_hi was added after d[] which makes
        csum_set calculate an unexpected super block checksum.
      
      To fix the above problems, this patch introduces a new incompat feature
      bit BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE, when this bit is set, it
      means bucket_size in struct cache_sb_disk stores the order of power-of-2
      bucket size value. When user specifies a bucket size larger than 32768
      sectors, BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE will be set to
      incompat feature set, and bucket_size stores log2(bucket size) more
      than store the real bucket size value.
      
      The obsoleted BCH_FEATURE_INCOMPAT_LARGE_BUCKET won't be used anymore,
      it is renamed to BCH_FEATURE_INCOMPAT_OBSO_LARGE_BUCKET and still only
      recognized by kernel driver for legacy compatible purpose. The previous
      bucket_size_hi is renmaed to obso_bucket_size_hi in struct cache_sb_disk
      and not used in bcache-tools anymore.
      
      For cache device created with BCH_FEATURE_INCOMPAT_LARGE_BUCKET feature,
      bcache-tools and kernel driver still recognize the feature string and
      display it as "obso_large_bucket".
      
      With this change, the unnecessary extra space extend of bcache on-disk
      super block can be avoided, and csum_set() may generate expected check
      sum as well.
      
      Fixes: ffa47032 ("bcache: add bucket_size_hi into struct cache_sb_disk for large bucket")
      Signed-off-by: NColy Li <colyli@suse.de>
      Cc: stable@vger.kernel.org # 5.9+
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      b16671e8
  3. 09 1月, 2021 1 次提交
  4. 08 1月, 2021 3 次提交
    • T
      KVM: SVM: Add support for booting APs in an SEV-ES guest · 647daca2
      Tom Lendacky 提交于
      Typically under KVM, an AP is booted using the INIT-SIPI-SIPI sequence,
      where the guest vCPU register state is updated and then the vCPU is VMRUN
      to begin execution of the AP. For an SEV-ES guest, this won't work because
      the guest register state is encrypted.
      
      Following the GHCB specification, the hypervisor must not alter the guest
      register state, so KVM must track an AP/vCPU boot. Should the guest want
      to park the AP, it must use the AP Reset Hold exit event in place of, for
      example, a HLT loop.
      
      First AP boot (first INIT-SIPI-SIPI sequence):
        Execute the AP (vCPU) as it was initialized and measured by the SEV-ES
        support. It is up to the guest to transfer control of the AP to the
        proper location.
      
      Subsequent AP boot:
        KVM will expect to receive an AP Reset Hold exit event indicating that
        the vCPU is being parked and will require an INIT-SIPI-SIPI sequence to
        awaken it. When the AP Reset Hold exit event is received, KVM will place
        the vCPU into a simulated HLT mode. Upon receiving the INIT-SIPI-SIPI
        sequence, KVM will make the vCPU runnable. It is again up to the guest
        to then transfer control of the AP to the proper location.
      
        To differentiate between an actual HLT and an AP Reset Hold, a new MP
        state is introduced, KVM_MP_STATE_AP_RESET_HOLD, which the vCPU is
        placed in upon receiving the AP Reset Hold exit event. Additionally, to
        communicate the AP Reset Hold exit event up to userspace (if needed), a
        new exit reason is introduced, KVM_EXIT_AP_RESET_HOLD.
      
      A new x86 ops function is introduced, vcpu_deliver_sipi_vector, in order
      to accomplish AP booting. For VMX, vcpu_deliver_sipi_vector is set to the
      original SIPI delivery function, kvm_vcpu_deliver_sipi_vector(). SVM adds
      a new function that, for non SEV-ES guests, invokes the original SIPI
      delivery function, kvm_vcpu_deliver_sipi_vector(), but for SEV-ES guests,
      implements the logic above.
      Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <e8fbebe8eb161ceaabdad7c01a5859a78b424d5e.1609791600.git.thomas.lendacky@amd.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      647daca2
    • A
      net/mlx5e: Add missing capability check for uplink follow · 9c9be85f
      Aya Levin 提交于
      Expose firmware indication that it supports setting eswitch uplink state
      to follow (follow the physical link). Condition setting the eswitch
      uplink admin-state with this capability bit. Older FW may not support
      the uplink state setting.
      
      Fixes: 7d0314b1 ("net/mlx5e: Modify uplink state on interface up/down")
      Signed-off-by: NAya Levin <ayal@nvidia.com>
      Reviewed-by: NMoshe Shemesh <moshe@nvidia.com>
      Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
      9c9be85f
    • S
      ACPI: scan: add stub acpi_create_platform_device() for !CONFIG_ACPI · ee61cfd9
      Shawn Guo 提交于
      It adds a stub acpi_create_platform_device() for !CONFIG_ACPI build, so
      that caller doesn't have to deal with !CONFIG_ACPI build issue.
      Reported-by: Nkernel test robot <lkp@intel.com>
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ee61cfd9
  5. 07 1月, 2021 3 次提交
  6. 06 1月, 2021 2 次提交
  7. 05 1月, 2021 1 次提交
  8. 04 1月, 2021 1 次提交
    • D
      afs: Fix directory entry size calculation · 366911cd
      David Howells 提交于
      The number of dirent records used by an AFS directory entry should be
      calculated using the assumption that there is a 16-byte name field in the
      first block, rather than a 20-byte name field (which is actually the case).
      This miscalculation is historic and effectively standard, so we have to use
      it.
      
      The calculation we need to use is:
      
      	1 + (((strlen(name) + 1) + 15) >> 5)
      
      where we are adding one to the strlen() result to account for the NUL
      termination.
      
      Fix this by the following means:
      
       (1) Create an inline function to do the calculation for a given name
           length.
      
       (2) Use the function to calculate the number of records used for a dirent
           in afs_dir_iterate_block().
      
           Use this to move the over-end check out of the loop since it only
           needs to be done once.
      
           Further use this to only go through the loop for the 2nd+ records
           composing an entry.  The only test there now is for if the record is
           allocated - and we already checked the first block at the top of the
           outer loop.
      
       (3) Add a max name length check in afs_dir_iterate_block().
      
       (4) Make afs_edit_dir_add() and afs_edit_dir_remove() use the function
           from (1) to calculate the number of blocks rather than doing it
           incorrectly themselves.
      
      Fixes: 63a4681f ("afs: Locally edit directory data for mkdir/create/unlink/...")
      Fixes: ^1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Tested-by: NMarc Dionne <marc.dionne@auristor.com>
      366911cd
  9. 30 12月, 2020 6 次提交
  10. 29 12月, 2020 2 次提交
  11. 28 12月, 2020 4 次提交
  12. 23 12月, 2020 13 次提交
  13. 22 12月, 2020 1 次提交
  14. 21 12月, 2020 1 次提交