qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 2dca1b: vfio/pci: add support for VF token


From: Richard Henderson
Subject: [Qemu-commits] [qemu/qemu] 2dca1b: vfio/pci: add support for VF token
Date: Wed, 10 May 2023 03:21:07 -0700

  Branch: refs/heads/staging
  Home:   https://github.com/qemu/qemu
  Commit: 2dca1b37a7605abb135559ef1b0d63929e7ae60d
      
https://github.com/qemu/qemu/commit/2dca1b37a7605abb135559ef1b0d63929e7ae60d
  Author: Minwoo Im <minwoo.im@samsung.com>
  Date:   2023-05-09 (Tue, 09 May 2023)

  Changed paths:
    M hw/vfio/pci.c
    M hw/vfio/pci.h

  Log Message:
  -----------
  vfio/pci: add support for VF token

VF token was introduced [1] to kernel vfio-pci along with SR-IOV
support [2].  This patch adds support VF token among PF and VF(s). To
passthu PCIe VF to a VM, kernel >= v5.7 needs this.

It can be configured with UUID like:

  -device vfio-pci,host=DDDD:BB:DD:F,vf-token=<uuid>,...

[1] 
https://lore.kernel.org/linux-pci/158396393244.5601.10297430724964025753.stgit@gimli.home/
[2] 
https://lore.kernel.org/linux-pci/158396044753.5601.14804870681174789709.stgit@gimli.home/

Cc: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Minwoo Im <minwoo.im@samsung.com>
Reviewed-by: Klaus Jensen <k.jensen@samsung.com>
Link: 
https://lore.kernel.org/r/20230320073522epcms2p48f682ecdb73e0ae1a4850ad0712fd780@epcms2p4
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>


  Commit: ff180c6bd7a8fad48099b767ad5e8340cec4fb87
      
https://github.com/qemu/qemu/commit/ff180c6bd7a8fad48099b767ad5e8340cec4fb87
  Author: Avihai Horon <avihaih@nvidia.com>
  Date:   2023-05-09 (Tue, 09 May 2023)

  Changed paths:
    M hw/vfio/common.c

  Log Message:
  -----------
  vfio/migration: Skip log_sync during migration SETUP state

Currently, VFIO log_sync can be issued while migration is in SETUP
state. However, doing this log_sync is at best redundant and at worst
can fail.

Redundant -- all RAM is marked dirty in migration SETUP state and is
transferred only after migration is set to ACTIVE state, so doing
log_sync during migration SETUP is pointless.

Can fail -- there is a time window, between setting migration state to
SETUP and starting dirty tracking by RAM save_live_setup handler, during
which dirty tracking is still not started. Any VFIO log_sync call that
is issued during this time window will fail. For example, this error can
be triggered by migrating a VM when a GUI is active, which constantly
calls log_sync.

Fix it by skipping VFIO log_sync while migration is in SETUP state.

Fixes: 758b96b61d5c ("vfio/migrate: Move switch of dirty tracking into 
vfio_memory_listener")
Signed-off-by: Avihai Horon <avihaih@nvidia.com>
Link: https://lore.kernel.org/r/20230403130000.6422-1-avihaih@nvidia.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>


  Commit: b5048a4cbfa0362abc720b5198fe9a35441bf5fe
      
https://github.com/qemu/qemu/commit/b5048a4cbfa0362abc720b5198fe9a35441bf5fe
  Author: Alex Williamson <alex.williamson@redhat.com>
  Date:   2023-05-09 (Tue, 09 May 2023)

  Changed paths:
    M hw/vfio/pci.c

  Log Message:
  -----------
  vfio/pci: Static Resizable BAR capability

The PCI Resizable BAR (ReBAR) capability is currently hidden from the
VM because the protocol for interacting with the capability does not
support a mechanism for the device to reject an advertised supported
BAR size.  However, when assigned to a VM, the act of resizing the
BAR requires adjustment of host resources for the device, which
absolutely can fail.  Linux does not currently allow us to reserve
resources for the device independent of the current usage.

The only writable field within the ReBAR capability is the BAR Size
register.  The PCIe spec indicates that when written, the device
should immediately begin to operate with the provided BAR size.  The
spec however also notes that software must only write values
corresponding to supported sizes as indicated in the capability and
control registers.  Writing unsupported sizes produces undefined
results.  Therefore, if the hypervisor were to virtualize the
capability and control registers such that the current size is the
only indicated available size, then a write of anything other than
the current size falls into the category of undefined behavior,
where we can essentially expose the modified ReBAR capability as
read-only.

This may seem pointless, but users have reported that virtualizing
the capability in this way not only allows guest software to expose
related features as available (even if only cosmetic), but in some
scenarios can resolve guest driver issues.  Additionally, no
regressions in behavior have been reported for this change.

A caveat here is that the PCIe spec requires for compatibility that
devices report support for a size in the range of 1MB to 512GB,
therefore if the current BAR size falls outside that range we revert
to hiding the capability.

Reviewed-by: C├ędric Le Goater <clg@redhat.com>
Link: 
https://lore.kernel.org/r/20230505232308.2869912-1-alex.williamson@redhat.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>


  Commit: b2896c1b09878fd1c4b485b3662f8beecbe0fef4
      
https://github.com/qemu/qemu/commit/b2896c1b09878fd1c4b485b3662f8beecbe0fef4
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2023-05-10 (Wed, 10 May 2023)

  Changed paths:
    M hw/vfio/common.c
    M hw/vfio/pci.c
    M hw/vfio/pci.h

  Log Message:
  -----------
  Merge tag 'vfio-updates-20230509.0' of 
https://gitlab.com/alex.williamson/qemu into staging

VFIO updates 2023-05-09

 * Add vf-token device option allowing QEMU to assign VFs where the PF
   is managed by a userspace driver. (Minwoo Im)

 * Skip log_sync during migration setup as a potential source of failure
   and likely source of redundancy. (Avihai Horon)

 * Virtualize PCIe Resizable BAR capability rather than hiding it,
   exposing only the current size as available. (Alex Williamson)

# -----BEGIN PGP SIGNATURE-----
#
# iQJPBAABCAA5FiEEQvbATlQL0amee4qQI5ubbjuwiyIFAmRaqfobHGFsZXgud2ls
# bGlhbXNvbkByZWRoYXQuY29tAAoJECObm247sIsiwNYP/2KtCbKqylnGPuwLbRMP
# HC4Id4mme7jUribmhM7FP57nQrb0tgnQoGvalkmB6M3833e3p4ivH2ezTyPxIawx
# UH4mAEBtR03rxh54eVBbOvDVf+XHd6qll/rFw5dBI0C5s7JQyMOourNRLTZLvqzD
# 2bwI7dfQzWbXWPj8QGPmDti9wbeATZ3RjqC7onoWq6A6Cw4aRGj1gHBQH9v81iA+
# m8hnZh+e5eFkQRc4mPXxFjm1Kw6ZYXWGoEEZrYPXvQn9+3MDCLcNb++KIrLsGujP
# qOnZG534vs+EZtUsGI8F02CBBXMAQFuBZhxCtuuG8iI9OQSE6R3E29iIc0Lpz5aO
# s8rN5OW4m7wXPdGkU1/7/N7kdeZvg+R8Jc4ozx3Mez3eSFbVkABSSX9vyvdHAezi
# 02Np1+ZBldZWBbBhYbWfqhvcg4iYNnHknSkS2CYY8jdsGttbrNY2f7Xllf3KC/Iv
# 6Un5WpU//0LuJjmH6onzswUUEmulchzR7OpBj68jFsB8rnTaZWM4Sqb/Jx+KXlRB
# BnNck0PCPoblpT8lgjAD3H9NaXx3mdVsml8i/7YIZjx8Zc4eanRGlsH9DmnHbB7U
# i4orDvL3SR3ZKVy6Zssti5jt8GwrEnqg97uTbS/jiTai1tOCP9n6U4T/wslHIUR4
# rIxvyJnmqrPAiWtVF+0cvGmT
# =VTJU
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 09 May 2023 09:15:54 PM BST
# gpg:                using RSA key 42F6C04E540BD1A99E7B8A90239B9B6E3BB08B22
# gpg:                issuer "alex.williamson@redhat.com"
# gpg: Good signature from "Alex Williamson <alex.williamson@redhat.com>" 
[undefined]
# gpg:                 aka "Alex Williamson <alex@shazbot.org>" [undefined]
# gpg:                 aka "Alex Williamson <alwillia@redhat.com>" [undefined]
# gpg:                 aka "Alex Williamson <alex.l.williamson@gmail.com>" 
[undefined]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 42F6 C04E 540B D1A9 9E7B  8A90 239B 9B6E 3BB0 8B22

* tag 'vfio-updates-20230509.0' of https://gitlab.com/alex.williamson/qemu:
  vfio/pci: Static Resizable BAR capability
  vfio/migration: Skip log_sync during migration SETUP state
  vfio/pci: add support for VF token

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>


Compare: https://github.com/qemu/qemu/compare/aab6a1b97322...b2896c1b0987



reply via email to

[Prev in Thread] Current Thread [Next in Thread]