All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Yunxiang Li <Yunxiang.Li@amd.com>
Cc: <kvm@vger.kernel.org>, <kevin.tian@intel.com>,
	<yishaih@nvidia.com>, <ankita@nvidia.com>, <jgg@ziepe.ca>
Subject: Re: [PATCH 2/3] vfio/pci: refactor vfio_pci_bar_rw
Date: Thu, 12 Dec 2024 16:00:30 -0700	[thread overview]
Message-ID: <20241212160030.18b376fa.alex.williamson@redhat.com> (raw)
In-Reply-To: <20241212205050.5737-2-Yunxiang.Li@amd.com>

On Thu, 12 Dec 2024 15:50:49 -0500
Yunxiang Li <Yunxiang.Li@amd.com> wrote:

> In the next patch the logic for reading ROM will get more complicated,
> so decouple the ROM path from the normal path. Also check that for ROM
> write is not allowed.

This is already enforced by the caller.  Vague references to the next
patch don't make a lot of sense once commits are in the tree, this
should describe what you're preparing for.

> 
> Signed-off-by: Yunxiang Li <Yunxiang.Li@amd.com>
> ---
>  drivers/vfio/pci/vfio_pci_rdwr.c | 47 ++++++++++++++++----------------
>  1 file changed, 24 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
> index a1eeacad82120..4bed9fd5af50f 100644
> --- a/drivers/vfio/pci/vfio_pci_rdwr.c
> +++ b/drivers/vfio/pci/vfio_pci_rdwr.c
> @@ -236,10 +236,9 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf,
>  	struct pci_dev *pdev = vdev->pdev;
>  	loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
>  	int bar = VFIO_PCI_OFFSET_TO_INDEX(*ppos);
> -	size_t x_start = 0, x_end = 0;
> +	size_t x_start, x_end;
>  	resource_size_t end;
>  	void __iomem *io;
> -	struct resource *res = &vdev->pdev->resource[bar];
>  	ssize_t done;
>  
>  	if (pci_resource_start(pdev, bar))
> @@ -253,41 +252,43 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf,
>  	count = min(count, (size_t)(end - pos));
>  
>  	if (bar == PCI_ROM_RESOURCE) {
> +		if (iswrite)
> +			return -EINVAL;
>  		/*
>  		 * The ROM can fill less space than the BAR, so we start the
>  		 * excluded range at the end of the actual ROM.  This makes
>  		 * filling large ROM BARs much faster.
>  		 */
>  		io = pci_map_rom(pdev, &x_start);
> -		if (!io) {
> -			done = -ENOMEM;
> -			goto out;
> -		}
> +		if (!io)
> +			return -ENOMEM;
>  		x_end = end;
> +
> +		done = vfio_pci_core_do_io_rw(vdev, 1, io, buf, pos,
> +					      count, x_start, x_end, 0);
> +
> +		pci_unmap_rom(pdev, io);
>  	} else {
> -		int ret = vfio_pci_core_setup_barmap(vdev, bar);
> -		if (ret) {
> -			done = ret;
> -			goto out;
> -		}
> +		done = vfio_pci_core_setup_barmap(vdev, bar);
> +		if (done)
> +			return done;
>  
>  		io = vdev->barmap[bar];
> -	}
>  
> -	if (bar == vdev->msix_bar) {
> -		x_start = vdev->msix_offset;
> -		x_end = vdev->msix_offset + vdev->msix_size;
> -	}
> +		if (bar == vdev->msix_bar) {
> +			x_start = vdev->msix_offset;
> +			x_end = vdev->msix_offset + vdev->msix_size;
> +		} else {
> +			x_start = 0;
> +			x_end = 0;
> +		}

There's a lot of semantic preference noise that obscures what you're
actually trying to accomplish here, effectively this has only
refactored the code to have separate calls to ..do_io_rw() for the ROM
vs other case and therefore pushed the unmap into the ROM case,
introducing various new exit paths.

>  
> -	done = vfio_pci_core_do_io_rw(vdev, res->flags & IORESOURCE_MEM, io, buf, pos,
> +		done = vfio_pci_core_do_io_rw(vdev, pci_resource_flags(pdev, bar) & IORESOURCE_MEM, io, buf, pos,

The line is too long already, now it's indented further and the
wrapping needs to be adjusted.

>  				      count, x_start, x_end, iswrite);
> -
> -	if (done >= 0)
> -		*ppos += done;
> -
> -	if (bar == PCI_ROM_RESOURCE)
> -		pci_unmap_rom(pdev, io);
> +	}
>  out:

Both goto's to this label were removed above, none added.  Thanks,

Alex

> +	if (done > 0)
> +		*ppos += done;
>  	return done;
>  }
>  


  reply	other threads:[~2024-12-12 23:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-12 20:50 [PATCH 1/3] vfio/pci: Remove shadow rom specific code paths Yunxiang Li
2024-12-12 20:50 ` [PATCH 2/3] vfio/pci: refactor vfio_pci_bar_rw Yunxiang Li
2024-12-12 23:00   ` Alex Williamson [this message]
2024-12-16 13:48     ` Li, Yunxiang (Teddy)
2024-12-20 12:36   ` kernel test robot
2024-12-20 20:22   ` kernel test robot
2024-12-12 20:50 ` [PATCH 3/3] vfio/pci: Expose setup ROM at ROM bar when needed Yunxiang Li
2024-12-12 23:00   ` Alex Williamson
2024-12-12 23:00 ` [PATCH 1/3] vfio/pci: Remove shadow rom specific code paths Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241212160030.18b376fa.alex.williamson@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=Yunxiang.Li@amd.com \
    --cc=ankita@nvidia.com \
    --cc=jgg@ziepe.ca \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=yishaih@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.