All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: <cohuck@redhat.com>, <kvm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <peterx@redhat.com>
Subject: Re: [PATCH 1/3] vfio: Introduce vma ops registration and notifier
Date: Thu, 18 Feb 2021 19:04:04 -0400	[thread overview]
Message-ID: <20210218230404.GD4247@nvidia.com> (raw)
In-Reply-To: <20210218145606.09f08044@omen.home.shazbot.org>

On Thu, Feb 18, 2021 at 02:56:06PM -0700, Alex Williamson wrote:

> Looks pretty slick.  I won't claim it's fully gelled in my head yet,
> but AIUI you're creating these inodes on your new pseudo fs and
> associating it via the actual user fd via the f_mapping pointer, which
> allows multiple fds to associate and address space back to this inode
> when you want to call unmap_mapping_range().  

Yes, from what I can tell all the fs/inode stuff is just mandatory
overhead to get a unique address_space pointer, as that is the only
thing this is actually using.

I have to check the mmap flow more carefully, I recall pointing to a
existing race here with Daniel, but the general idea should hold.

> That clarifies from the previous email how we'd store the inode on
> the vfio_device without introducing yet another tracking list for
> device fds.

Right, you can tell from the vma what inode it is for, and the inode
can tell you if it is a VFIO VMA or not, so no tracking lists needed
at all.

Jason

  reply	other threads:[~2021-02-18 23:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-12 19:27 [PATCH 0/3] vfio: Device memory DMA mapping improvements Alex Williamson
2021-02-12 19:27 ` [PATCH 1/3] vfio: Introduce vma ops registration and notifier Alex Williamson
2021-02-12 21:20   ` Jason Gunthorpe
2021-02-18  1:12     ` Jason Gunthorpe
2021-02-18 21:56       ` Alex Williamson
2021-02-18 23:04         ` Jason Gunthorpe [this message]
2021-02-19 22:02           ` Alex Williamson
2021-02-12 19:27 ` [PATCH 2/3] vfio/pci: Implement vm_ops registration Alex Williamson
2021-02-12 19:28 ` [PATCH 3/3] vfio/type1: Implement vma registration and restriction Alex Williamson
2021-02-12 22:47   ` kernel test robot
2021-02-12 22:47     ` kernel test robot
2021-02-12 20:57 ` [PATCH 0/3] vfio: Device memory DMA mapping improvements Jason Gunthorpe

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=20210218230404.GD4247@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterx@redhat.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.