All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Tom Lyon <pugs@cisco.com>,
	linux-pci@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	randy.dunlap@oracle.com, arnd@arndb.de, joro@8bytes.org,
	hjk@linutronix.de, avi@redhat.com, gregkh@suse.de,
	chrisw@sous-sol.org
Subject: Re: [PATCH 3/3] VFIO V4: VFIO driver: Non-privileged user level PCI drivers
Date: Mon, 27 Sep 2010 14:57:49 -0600	[thread overview]
Message-ID: <1285621069.4951.61.camel@x201> (raw)
In-Reply-To: <20100927115420.GA7427@redhat.com>

On Mon, 2010-09-27 at 13:54 +0200, Michael S. Tsirkin wrote:
> On Wed, Sep 22, 2010 at 02:18:24PM -0700, Tom Lyon wrote:
> > 
> > Signed-off-by: Tom Lyon <pugs@cisco.com>
> 
> Some comments on the pci bits:
> 
> After going over them for the Nth time - something needs to be done
> with the rvirt/write tables. I doubt anyone besides me and you
> has gone over them: 

/me bites tongue...

> > +static void vfio_bar_fixup(struct vfio_dev *vdev)
> > +{
> 
> So you do this on each read?
> Why don't you mask the appropriate bits on write?
> This is what real hardware does, after all.
> Then you won't need the bardirty field.
> 
> 
> > +	struct pci_dev *pdev = vdev->pdev;
> > +	int bar;
> > +	u32 *lp;
> > +	u64 mask;
> > +
> > +	for (bar = 0; bar <= 5; bar++) {
> > +		if (pci_resource_start(pdev, bar))
> > +			mask = ~(pci_resource_len(pdev, bar) - 1);
> > +		else
> > +			mask = 0;
> > +		lp = (u32 *)vdev->vconfig + PCI_BASE_ADDRESS_0 + 4*bar;
> > +		*lp &= (u32)mask;
> > +
> > +		if (pci_resource_flags(pdev, bar) & IORESOURCE_IO)
> > +			*lp |= PCI_BASE_ADDRESS_SPACE_IO;
> > +		else if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM) {
> > +			*lp |= PCI_BASE_ADDRESS_SPACE_MEMORY;
> > +			if (pci_resource_flags(pdev, bar) & IORESOURCE_PREFETCH)
> > +				*lp |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> > +			if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM_64) {
> > +				*lp |= PCI_BASE_ADDRESS_MEM_TYPE_64;
> > +				lp++;
> > +				*lp &= (u32)(mask >> 32);
> > +				bar++;
> > +			}
> > +		}
> > +	}
> > +
> > +	if (pci_resource_start(pdev, PCI_ROM_RESOURCE))
> 
> Not if (pci_resource_len)?

Using this test covers both zero length/unimplemented BARs and BARs that
aren't mapped by the host.  Unmapped BARs on the host are exposed as
unimplemented BARs to the vfio user.  I wonder if this is still
necessary if we do the iomap/rom_map on open as I propose.

> > +		mask = ~(pci_resource_len(pdev, PCI_ROM_RESOURCE) - 1);
> > +	else
> > +		mask = 0;
> > +	lp = (u32 *)vdev->vconfig + PCI_ROM_ADDRESS;
> > +	*lp &= (u32)mask;
> > +
> > +	vdev->bardirty = 0;
> 
> Aren't the pci values in little endian format?
> If so doing operations on them in native endianness is wrong.
> sparse generally is good at catching these, but you will
> have to avoid so many type casts and annotate endian-ness
> for it to be of any use.

Yep, I expect there are a number of endian issues here, good call
pointing them out.

Alex


  reply	other threads:[~2010-09-27 20:58 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-22 21:18 [PATCH 3/3] VFIO V4: VFIO driver: Non-privileged user level PCI drivers Tom Lyon
2010-09-22 21:18 ` Tom Lyon
2010-09-26 14:54 ` Michael S. Tsirkin
2010-09-30 21:43   ` Tom Lyon
2010-10-03 12:27     ` Michael S. Tsirkin
2010-09-27 11:54 ` Michael S. Tsirkin
2010-09-27 20:57   ` Alex Williamson [this message]
2010-09-28 10:14     ` Michael S. Tsirkin
2010-09-30 23:09   ` Tom Lyon
2010-10-03 13:02     ` Michael S. Tsirkin
2010-09-27 20:41 ` Alex Williamson
2010-10-15 22:29   ` Tom Lyon
2010-09-27 20:46 ` Alex Williamson
2010-09-28 10:09   ` Michael S. Tsirkin
2010-09-28 14:26     ` Alex Williamson
2010-09-28 14:40       ` Michael S. Tsirkin
2010-09-28 17:10         ` Alex Williamson
2010-09-28 17:36           ` Michael S. Tsirkin
  -- strict thread matches above, loose matches on Subject: below --
2010-09-23 12:58 Andy Walls
2010-09-23 19:33 ` Tom Lyon

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=1285621069.4951.61.camel@x201 \
    --to=alex.williamson@redhat.com \
    --cc=arnd@arndb.de \
    --cc=avi@redhat.com \
    --cc=chrisw@sous-sol.org \
    --cc=gregkh@suse.de \
    --cc=hjk@linutronix.de \
    --cc=jbarnes@virtuousgeek.org \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=pugs@cisco.com \
    --cc=randy.dunlap@oracle.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.