[Qemu-devel] [PATCH for-2.4 0/2] vfio-pci: Fixes for fixes

[Qemu-devel] [PATCH for-2.4 0/2] vfio-pci: Fixes for fixes

[Alex Williamson]

Fix a couple issues spotted by Laszlo in downstream review.  Thanks,

Alex

---

Alex Williamson (2):
      vfio-pci: Further fix BAR size overflow
      vfio-pci: Fix error path sign


 hw/vfio/pci.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

[Qemu-devel] [PATCH for-2.4 1/2] vfio-pci: Further fix BAR size overflow

[Alex Williamson]

In an analysis by Laszlo, the resulting type of our calculation for
the end of the MSI-X table, and thus the start of memory after the
table, is uint32_t.  We're therefore not correctly preventing the
corner case overflow that we intended to fix here where a BAR >=4G
could place the MSI-X table to end exactly at the 4G boundary.  The
MSI-X table offset is defined by the hardware spec to 32bits, so we
simply use a cast rather than changing data structure types.  This
scenario is purely theoretically, typically the MSI-X table is located
at the front of the BAR.

Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
 hw/vfio/pci.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 6b80539..d387fbd 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -2394,7 +2394,7 @@ static void vfio_map_bar(VFIOPCIDevice *vdev, int nr)
     if (vdev->msix && vdev->msix->table_bar == nr) {
         uint64_t start;
 
-        start = HOST_PAGE_ALIGN(vdev->msix->table_offset +
+        start = HOST_PAGE_ALIGN((uint64_t)vdev->msix->table_offset +
                                 (vdev->msix->entries * PCI_MSIX_ENTRY_SIZE));
 
         size = start < bar->region.size ? bar->region.size - start : 0;

[Qemu-devel] [PATCH for-2.4 2/2] vfio-pci: Fix error path sign

[Alex Williamson]

This is an impossible error path due to the fact that we're reading a
kernel provided, rather than user provided link, which will certainly
always fit in PATH_MAX.  Currently it returns a fixed 26 char path
plus %d group number, which typically maxes out at double digits.
However, the caller of the initfn certainly expects a less-than zero
return value on error, not just a non-zero value.  Therefore we
should correct the sign here.

Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
 hw/vfio/pci.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index d387fbd..ebc1e0a 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -3352,7 +3352,7 @@ static int vfio_initfn(PCIDevice *pdev)
     len = readlink(path, iommu_group_path, sizeof(path));
     if (len <= 0 || len >= sizeof(path)) {
         error_report("vfio: error no iommu_group for device");
-        return len < 0 ? -errno : ENAMETOOLONG;
+        return len < 0 ? -errno : -ENAMETOOLONG;
     }
 
     iommu_group_path[len] = 0;

Re: [Qemu-devel] [PATCH for-2.4 0/2] vfio-pci: Fixes for fixes

[Laszlo Ersek]

On 04/16/15 20:00, Alex Williamson wrote:
> Fix a couple issues spotted by Laszlo in downstream review.  Thanks,
> 
> Alex
> 
> ---
> 
> Alex Williamson (2):
>       vfio-pci: Further fix BAR size overflow
>       vfio-pci: Fix error path sign
> 
> 
>  hw/vfio/pci.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

series
Reviewed-by: Laszlo Ersek <lersek@redhat.com>

Thanks!
Laszlo