<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/vfio/pci, branch linux-5.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.9.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.9.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2020-11-18T18:22:13Z</updated>
<entry>
<title>vfio/pci: Bypass IGD init in case of -ENODEV</title>
<updated>2020-11-18T18:22:13Z</updated>
<author>
<name>Fred Gao</name>
</author>
<published>2020-11-02T18:01:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fdcbd5e015f9b654abb1cf9805f824e067016c7f'/>
<id>urn:sha1:fdcbd5e015f9b654abb1cf9805f824e067016c7f</id>
<content type='text'>
[ Upstream commit e4eccb853664de7bcf9518fb658f35e748bf1f68 ]

Bypass the IGD initialization when -ENODEV returns,
that should be the case if opregion is not available for IGD
or within discrete graphics device's option ROM,
or host/lpc bridge is not found.

Then use of -ENODEV here means no special device resources found
which needs special care for VFIO, but we still allow other normal
device resource access.

Cc: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Cc: Xiong Zhang &lt;xiong.y.zhang@intel.com&gt;
Cc: Hang Yuan &lt;hang.yuan@linux.intel.com&gt;
Cc: Stuart Summers &lt;stuart.summers@intel.com&gt;
Signed-off-by: Fred Gao &lt;fred.gao@intel.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>vfio/pci: Implement ioeventfd thread handler for contended memory lock</title>
<updated>2020-11-18T18:22:04Z</updated>
<author>
<name>Alex Williamson</name>
</author>
<published>2020-11-02T22:02:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0a444bd17a83cbf213e432dfe46bece9e37b6847'/>
<id>urn:sha1:0a444bd17a83cbf213e432dfe46bece9e37b6847</id>
<content type='text'>
[ Upstream commit 38565c93c8a1306dc5f245572a545fbea908ac41 ]

The ioeventfd is called under spinlock with interrupts disabled,
therefore if the memory lock is contended defer code that might
sleep to a thread context.

Fixes: bc93b9ae0151 ("vfio-pci: Avoid recursive read-lock usage")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=209253#c1
Reported-by: Ian Pilcher &lt;arequipeno@gmail.com&gt;
Tested-by: Ian Pilcher &lt;arequipeno@gmail.com&gt;
Tested-by: Justin Gatzen &lt;justin.gatzen@gmail.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>vfio/pci: Clear token on bypass registration failure</title>
<updated>2020-10-29T09:11:57Z</updated>
<author>
<name>Alex Williamson</name>
</author>
<published>2020-10-19T13:13:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=098b4078cc75634a710c83f5294886121371f48b'/>
<id>urn:sha1:098b4078cc75634a710c83f5294886121371f48b</id>
<content type='text'>
[ Upstream commit 852b1beecb6ff9326f7ca4bc0fe69ae860ebdb9e ]

The eventfd context is used as our irqbypass token, therefore if an
eventfd is re-used, our token is the same.  The irqbypass code will
return an -EBUSY in this case, but we'll still attempt to unregister
the producer, where if that duplicate token still exists, results in
removing the wrong object.  Clear the token of failed producers so
that they harmlessly fall out when unregistered.

Fixes: 6d7425f109d2 ("vfio: Register/unregister irq_bypass_producer")
Reported-by: guomin chen &lt;guomin_chen@sina.com&gt;
Tested-by: guomin chen &lt;guomin_chen@sina.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>vfio/pci: Decouple PCI_COMMAND_MEMORY bit checks from is_virtfn</title>
<updated>2020-10-29T09:11:54Z</updated>
<author>
<name>Matthew Rosato</name>
</author>
<published>2020-09-10T14:59:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ccca9dae4f128ff733f7b196bff1155e89268620'/>
<id>urn:sha1:ccca9dae4f128ff733f7b196bff1155e89268620</id>
<content type='text'>
[ Upstream commit 515ecd5368f1510152fa4f9b9ce55b66ac56c334 ]

While it is true that devices with is_virtfn=1 will have a Memory Space
Enable bit that is hard-wired to 0, this is not the only case where we
see this behavior -- For example some bare-metal hypervisors lack
Memory Space Enable bit emulation for devices not setting is_virtfn
(s390). Fix this by instead checking for the newly-added
no_command_memory bit which directly denotes the need for
PCI_COMMAND_MEMORY emulation in vfio.

Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory")
Signed-off-by: Matthew Rosato &lt;mjrosato@linux.ibm.com&gt;
Reviewed-by: Niklas Schnelle &lt;schnelle@linux.ibm.com&gt;
Reviewed-by: Pierre Morel &lt;pmorel@linux.ibm.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>treewide: Use fallthrough pseudo-keyword</title>
<updated>2020-08-23T22:36:59Z</updated>
<author>
<name>Gustavo A. R. Silva</name>
</author>
<published>2020-08-23T22:36:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=df561f6688fef775baa341a0f5d960becd248b11'/>
<id>urn:sha1:df561f6688fef775baa341a0f5d960becd248b11</id>
<content type='text'>
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva &lt;gustavoars@kernel.org&gt;
</content>
</entry>
<entry>
<title>vfio-pci: Avoid recursive read-lock usage</title>
<updated>2020-08-17T17:08:18Z</updated>
<author>
<name>Alex Williamson</name>
</author>
<published>2020-08-17T17:08:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bc93b9ae0151ae5ad5b8504cdc598428ea99570b'/>
<id>urn:sha1:bc93b9ae0151ae5ad5b8504cdc598428ea99570b</id>
<content type='text'>
A down_read on memory_lock is held when performing read/write accesses
to MMIO BAR space, including across the copy_to/from_user() callouts
which may fault.  If the user buffer for these copies resides in an
mmap of device MMIO space, the mmap fault handler will acquire a
recursive read-lock on memory_lock.  Avoid this by reducing the lock
granularity.  Sequential accesses requiring multiple ioread/iowrite
cycles are expected to be rare, therefore typical accesses should not
see additional overhead.

VGA MMIO accesses are expected to be non-fatal regardless of the PCI
memory enable bit to allow legacy probing, this behavior remains with
a comment added.  ioeventfds are now included in memory access testing,
with writes dropped while memory space is disabled.

Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory")
Reported-by: Zhiyi Guo &lt;zhguo@redhat.com&gt;
Tested-by: Zhiyi Guo &lt;zhguo@redhat.com&gt;
Reviewed-by: Cornelia Huck &lt;cohuck@redhat.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
</content>
</entry>
<entry>
<title>vfio/pci: Add QAT devices to denylist</title>
<updated>2020-07-27T19:43:40Z</updated>
<author>
<name>Giovanni Cabiddu</name>
</author>
<published>2020-07-27T19:43:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=50173329c8cc0c892eaa7a9d0f0692ac39cd7b04'/>
<id>urn:sha1:50173329c8cc0c892eaa7a9d0f0692ac39cd7b04</id>
<content type='text'>
The current generation of Intel® QuickAssist Technology devices
are not designed to run in an untrusted environment because of the
following issues reported in the document "Intel® QuickAssist Technology
(Intel® QAT) Software for Linux" (document number 336211-014):

QATE-39220 - GEN - Intel® QAT API submissions with bad addresses that
             trigger DMA to invalid or unmapped addresses can cause a
             platform hang
QATE-7495  - GEN - An incorrectly formatted request to Intel® QAT can
             hang the entire Intel® QAT Endpoint

The document is downloadable from https://01.org/intel-quickassist-technology
at the following link:
https://01.org/sites/default/files/downloads/336211-014-qatforlinux-releasenotes-hwv1.7_0.pdf

This patch adds the following QAT devices to the denylist: DH895XCC,
C3XXX and C62X.

Signed-off-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Reviewed-by: Fiona Trahe &lt;fiona.trahe@intel.com&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
</content>
</entry>
<entry>
<title>vfio/pci: Add device denylist</title>
<updated>2020-07-27T19:43:40Z</updated>
<author>
<name>Giovanni Cabiddu</name>
</author>
<published>2020-07-27T19:43:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1f97970e6c8e60349b045599f4525608db895009'/>
<id>urn:sha1:1f97970e6c8e60349b045599f4525608db895009</id>
<content type='text'>
Add denylist of devices that by default are not probed by vfio-pci.
Devices in this list may be susceptible to untrusted application, even
if the IOMMU is enabled. To be accessed via vfio-pci, the user has to
explicitly disable the denylist.

The denylist can be disabled via the module parameter disable_denylist.

Signed-off-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Reviewed-by: Cornelia Huck &lt;cohuck@redhat.com&gt;
Reviewed-by: Fiona Trahe &lt;fiona.trahe@intel.com&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
</content>
</entry>
<entry>
<title>vfio/pci: Hold igate across releasing eventfd contexts</title>
<updated>2020-07-27T19:43:38Z</updated>
<author>
<name>Alex Williamson</name>
</author>
<published>2020-07-27T19:43:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=924b51abf961f1d888143fcfa3d63c92dc517679'/>
<id>urn:sha1:924b51abf961f1d888143fcfa3d63c92dc517679</id>
<content type='text'>
No need to release and immediately re-acquire igate while clearing
out the eventfd ctxs.

Reviewed-by: Cornelia Huck &lt;cohuck@redhat.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
</content>
</entry>
<entry>
<title>vfio/pci: Add Intel X550 to hidden INTx devices</title>
<updated>2020-07-27T19:43:37Z</updated>
<author>
<name>Alex Williamson</name>
</author>
<published>2020-07-27T19:43:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bf3551e150e5a231ac60f2bd750f63ab5484010a'/>
<id>urn:sha1:bf3551e150e5a231ac60f2bd750f63ab5484010a</id>
<content type='text'>
Intel document 333717-008, "Intel® Ethernet Controller X550
Specification Update", version 2.7, dated June 2020, includes errata
#22, added in version 2.1, May 2016, indicating X550 NICs suffer from
the same implementation deficiency as the 700-series NICs:

"The Interrupt Status bit in the Status register of the PCIe
 configuration space is not implemented and is not set as described
 in the PCIe specification."

Without the interrupt status bit, vfio-pci cannot determine when
these devices signal INTx.  They are therefore added to the nointx
quirk.

Cc: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
</content>
</entry>
</feed>
