<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/vfio/pci, branch linux-4.16.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.16.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.16.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-03-22T04:50:19+00:00</updated>
<entry>
<title>Revert: "vfio-pci: Mask INTx if a device is not capabable of enabling it"</title>
<updated>2018-03-22T04:50:19+00:00</updated>
<author>
<name>Alex Williamson</name>
<email>alex.williamson@redhat.com</email>
</author>
<published>2018-03-22T04:50:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=834814e80268c818f354c8f402e0c6604ed75589'/>
<id>urn:sha1:834814e80268c818f354c8f402e0c6604ed75589</id>
<content type='text'>
This reverts commit 2170dd04316e0754cbbfa4892a25aead39d225f7

The intent of commit 2170dd04316e ("vfio-pci: Mask INTx if a device is
not capabable of enabling it") was to disallow the user from seeing
that the device supports INTx if the platform is incapable of enabling
it.  The detection of this case however incorrectly includes devices
which natively do not support INTx, such as SR-IOV VFs, and further
discussions reveal gaps even for the target use case.

Reported-by: Arjun Vynipadath &lt;arjun@chelsio.com&gt;
Fixes: 2170dd04316e ("vfio-pci: Mask INTx if a device is not capabable of enabling it")
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
</content>
</entry>
<entry>
<title>vfio-pci: Allow mapping MSIX BAR</title>
<updated>2017-12-20T17:05:06+00:00</updated>
<author>
<name>Alexey Kardashevskiy</name>
<email>aik@ozlabs.ru</email>
</author>
<published>2017-12-13T02:31:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a32295c612c57990d17fb0f41e7134394b2f35f6'/>
<id>urn:sha1:a32295c612c57990d17fb0f41e7134394b2f35f6</id>
<content type='text'>
By default VFIO disables mapping of MSIX BAR to the userspace as
the userspace may program it in a way allowing spurious interrupts;
instead the userspace uses the VFIO_DEVICE_SET_IRQS ioctl.
In order to eliminate guessing from the userspace about what is
mmapable, VFIO also advertises a sparse list of regions allowed to mmap.

This works fine as long as the system page size equals to the MSIX
alignment requirement which is 4KB. However with a bigger page size
the existing code prohibits mapping non-MSIX parts of a page with MSIX
structures so these parts have to be emulated via slow reads/writes on
a VFIO device fd. If these emulated bits are accessed often, this has
serious impact on performance.

This allows mmap of the entire BAR containing MSIX vector table.

This removes the sparse capability for PCI devices as it becomes useless.

As the userspace needs to know for sure whether mmapping of the MSIX
vector containing data can succeed, this adds a new capability -
VFIO_REGION_INFO_CAP_MSIX_MAPPABLE - which explicitly tells the userspace
that the entire BAR can be mmapped.

This does not touch the MSIX mangling in the BAR read/write handlers as
we are doing this just to enable direct access to non MSIX registers.

Signed-off-by: Alexey Kardashevskiy &lt;aik@ozlabs.ru&gt;
[aw - fixup whitespace, trim function name]
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
</content>
</entry>
<entry>
<title>vfio: Simplify capability helper</title>
<updated>2017-12-20T16:53:54+00:00</updated>
<author>
<name>Alex Williamson</name>
<email>alex.williamson@redhat.com</email>
</author>
<published>2017-12-12T19:59:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dda01f787df9f9e46f1c0bf8aa11f246e300750d'/>
<id>urn:sha1:dda01f787df9f9e46f1c0bf8aa11f246e300750d</id>
<content type='text'>
The vfio_info_add_capability() helper requires the caller to pass a
capability ID, which it then uses to fill in header fields, assuming
hard coded versions.  This makes for an awkward and rigid interface.
The only thing we want this helper to do is allocate sufficient
space in the caps buffer and chain this capability into the list.
Reduce it to that simple task.

Reviewed-by: Alexey Kardashevskiy &lt;aik@ozlabs.ru&gt;
Acked-by: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Reviewed-by: Kirti Wankhede &lt;kwankhede@nvidia.com&gt;
Reviewed-by: Peter Xu &lt;peterx@redhat.com&gt;
Reviewed-by: Eric Auger &lt;eric.auger@redhat.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
</content>
</entry>
<entry>
<title>vfio-pci: Mask INTx if a device is not capabable of enabling it</title>
<updated>2017-12-20T16:53:52+00:00</updated>
<author>
<name>Alexey Kardashevskiy</name>
<email>aik@ozlabs.ru</email>
</author>
<published>2017-12-07T01:56:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2170dd04316e0754cbbfa4892a25aead39d225f7'/>
<id>urn:sha1:2170dd04316e0754cbbfa4892a25aead39d225f7</id>
<content type='text'>
At the moment VFIO rightfully assumes that INTx is supported if
the interrupt pin is not set to zero in the device config space.
However if that is not the case (the pin is not zero but pdev-&gt;irq is),
vfio_intx_enable() fails.

In order to prevent the userspace from trying to enable INTx when we know
that it cannot work, let's mask the PCI_INTERRUPT_PIN register.

Signed-off-by: Alexey Kardashevskiy &lt;aik@ozlabs.ru&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
</content>
</entry>
<entry>
<title>vfio/pci: Virtualize Maximum Read Request Size</title>
<updated>2017-10-02T18:39:10+00:00</updated>
<author>
<name>Alex Williamson</name>
<email>alex.williamson@redhat.com</email>
</author>
<published>2017-10-02T18:39:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cf0d53ba4947aad6e471491d5b20a567cbe92e56'/>
<id>urn:sha1:cf0d53ba4947aad6e471491d5b20a567cbe92e56</id>
<content type='text'>
MRRS defines the maximum read request size a device is allowed to
make.  Drivers will often increase this to allow more data transfer
with a single request.  Completions to this request are bound by the
MPS setting for the bus.  Aside from device quirks (none known), it
doesn't seem to make sense to set an MRRS value less than MPS, yet
this is a likely scenario given that user drivers do not have a
system-wide view of the PCI topology.  Virtualize MRRS such that the
user can set MRRS &gt;= MPS, but use MPS as the floor value that we'll
write to hardware.

Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
</content>
</entry>
<entry>
<title>vfio/pci: Virtualize Maximum Payload Size</title>
<updated>2017-10-02T18:39:09+00:00</updated>
<author>
<name>Alex Williamson</name>
<email>alex.williamson@redhat.com</email>
</author>
<published>2017-10-02T18:39:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=523184972b282cd9ca17a76f6ca4742394856818'/>
<id>urn:sha1:523184972b282cd9ca17a76f6ca4742394856818</id>
<content type='text'>
With virtual PCI-Express chipsets, we now see userspace/guest drivers
trying to match the physical MPS setting to a virtual downstream port.
Of course a lone physical device surrounded by virtual interconnects
cannot make a correct decision for a proper MPS setting.  Instead,
let's virtualize the MPS control register so that writes through to
hardware are disallowed.  Userspace drivers like QEMU assume they can
write anything to the device and we'll filter out anything dangerous.
Since mismatched MPS can lead to AER and other faults, let's add it
to the kernel side rather than relying on userspace virtualization to
handle it.

Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Reviewed-by: Eric Auger &lt;eric.auger@redhat.com&gt;
</content>
</entry>
<entry>
<title>vfio/pci: Fix handling of RC integrated endpoint PCIe capability size</title>
<updated>2017-07-27T16:39:33+00:00</updated>
<author>
<name>Alex Williamson</name>
<email>alex.williamson@redhat.com</email>
</author>
<published>2017-07-27T16:39:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=796b755066dd6254bfb6388fec901631e868d1c7'/>
<id>urn:sha1:796b755066dd6254bfb6388fec901631e868d1c7</id>
<content type='text'>
Root complex integrated endpoints do not have a link and therefore may
use a smaller PCIe capability in config space than we expect when
building our config map.  Add a case for these to avoid reporting an
erroneous overlap.

Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
</content>
</entry>
<entry>
<title>vfio/pci: Use pci_try_reset_function() on initial open</title>
<updated>2017-07-26T20:33:15+00:00</updated>
<author>
<name>Alex Williamson</name>
<email>alex.williamson@redhat.com</email>
</author>
<published>2017-07-26T20:33:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9f47803503247c9ec414072c0724073a1c8c3433'/>
<id>urn:sha1:9f47803503247c9ec414072c0724073a1c8c3433</id>
<content type='text'>
Device lock bites again; if a device .remove() callback races a user
calling ioctl(VFIO_GROUP_GET_DEVICE_FD), the unbind request will hold
the device lock, but the user ioctl may have already taken a vfio_device
reference.  In the case of a PCI device, the initial open will attempt
to reset the device, which again attempts to get the device lock,
resulting in deadlock.  Use the trylock PCI reset interface and return
error on the open path if reset fails due to lock contention.

Link: https://lkml.org/lkml/2017/7/25/381
Reported-by: Wen Congyang &lt;wencongyang2@huawei.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
</content>
</entry>
<entry>
<title>vfio/pci: Add Intel XXV710 to hidden INTx devices</title>
<updated>2017-06-13T15:22:57+00:00</updated>
<author>
<name>Alex Williamson</name>
<email>alex.williamson@redhat.com</email>
</author>
<published>2017-06-13T15:22:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7d57e5e933674c116e46f30eee7629c20f9073da'/>
<id>urn:sha1:7d57e5e933674c116e46f30eee7629c20f9073da</id>
<content type='text'>
XXV710 has the same broken INTx behavior as the rest of the X/XL710
series, the interrupt status register is not wired to report pending
INTx interrupts, thus we never associate the interrupt to the device.
Extend the device IDs to include these so that we hide that the
device supports INTx at all to the user.

Reported-by: Stefan Assmann &lt;sassmann@redhat.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Acked-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
</content>
</entry>
<entry>
<title>vfio-pci: Handle error from pci_iomap</title>
<updated>2017-01-04T15:34:39+00:00</updated>
<author>
<name>Arvind Yadav</name>
<email>arvind.yadav.cs@gmail.com</email>
</author>
<published>2017-01-03T11:56:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e19f32da5ded958238eac1bbe001192acef191a2'/>
<id>urn:sha1:e19f32da5ded958238eac1bbe001192acef191a2</id>
<content type='text'>
Here, pci_iomap can fail, handle this case release selected
pci regions and return -ENOMEM.

Signed-off-by: Arvind Yadav &lt;arvind.yadav.cs@gmail.com&gt;
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
</content>
</entry>
</feed>
