aboutsummaryrefslogtreecommitdiff
path: root/cpus-common.c
diff options
context:
space:
mode:
authorAlex Williamson <alex.williamson@redhat.com>2017-02-22 13:19:58 -0700
committerAlex Williamson <alex.williamson@redhat.com>2017-02-22 13:19:58 -0700
commitd0d1cd70d10639273e2a23870e7e7d80b2bc4e21 (patch)
treec7548e7fa33f99f6310115d7ceea302268d62aa4 /cpus-common.c
parent35c7cb4caff66fe4c01711243d42de4445cb83e2 (diff)
downloadqemu-d0d1cd70d10639273e2a23870e7e7d80b2bc4e21.zip
qemu-d0d1cd70d10639273e2a23870e7e7d80b2bc4e21.tar.gz
qemu-d0d1cd70d10639273e2a23870e7e7d80b2bc4e21.tar.bz2
vfio/pci: Improve extended capability comments, skip masked caps
Since commit 4bb571d857d9 ("pci/pcie: don't assume cap id 0 is reserved") removes the internal use of extended capability ID 0, the comment here becomes invalid. However, peeling back the onion, the code is still correct and we still can't seed the capability chain with ID 0, unless we want to muck with using the version number to force the header to be non-zero, which is much uglier to deal with. The comment also now covers some of the subtleties of using cap ID 0, such as transparently indicating absence of capabilities if none are added. This doesn't detract from the correctness of the referenced commit as vfio in the kernel also uses capability ID zero to mask capabilties. In fact, we should skip zero capabilities precisely because the kernel might also expose such a capability at the head position and re-introduce the problem. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Tested-by: Peter Xu <peterx@redhat.com> Reported-by: Jintack Lim <jintack@cs.columbia.edu> Tested-by: Jintack Lim <jintack@cs.columbia.edu>
Diffstat (limited to 'cpus-common.c')
0 files changed, 0 insertions, 0 deletions