All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Thanos Makatos <thanos.makatos@nutanix.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Martins, Joao" <joao.m.martins@oracle.com>,
	John Levon <john.levon@nutanix.com>,
	"john.g.johnson@oracle.com" <john.g.johnson@oracle.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Eric Auger <eric.auger@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	"Liu, Yi L" <yi.l.liu@intel.com>
Subject: Re: iommufd dirty page logging overview
Date: Fri, 18 Mar 2022 09:41:08 -0300	[thread overview]
Message-ID: <20220318124108.GF11336@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB52765646E6837CE3BF5979988C139@BN9PR11MB5276.namprd11.prod.outlook.com>

On Fri, Mar 18, 2022 at 09:23:49AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Thursday, March 17, 2022 7:51 AM
> > 
> > > there a rough idea of how the new dirty page logging will look like?
> > > Is this already explained in the email threads an I missed it?
> > 
> > I'm hoping to get something to show in the next few weeks, but what
> > I've talked about previously is to have two things:
> > 
> > 1) Control and reporting of dirty tracking via the system IOMMU
> >    through the iommu_domain interface exposed by iommufd
> > 
> > 2) Control and reporting of dirty tracking via a VFIO migration
> >    capable device's internal tracking through a VFIO_DEVICE_FEATURE
> >    interface similar to the v2 migration interface
> > 
> > The two APIs would be semantically very similar but target different
> > HW blocks. Userspace would be in charge to decide which dirty tracker
> > to use and how to configure it.
> > 
> 
> for the 2nd option I suppose userspace is expected to retrieve
> dirty bits via VFIO_DEVICE_FEATURE before every iommufd 
> unmap operation in precopy phase, just like why we need return
> the dirty bitmap to userspace in iommufd unmap interface in
> the 1st option. Correct?

It would have to be after unmap, not before

> Is there any value of having iommufd pull dirty bitmap from
> vfio driver then the userspace can just stick to a unified
> iommufd interface for dirty pages no matter they are tracked
> by system IOMMU or device IP? Sorry if this has been discussed
> in previous threads which I haven't fully checked.

It is something to discuss, this is sort of what the current vfio
interface imagines

But to do it we need to build a whole bunch of infrastructure to
register and control these things and add new ioctls to vfio to
support this. I'm not sure we get a sufficient benifit to be
worthwhile, infact it is probably a net loss as we loose the ability
for userspace to pull the dirty bits from multiple device trackers in
parallel with threading.

Jason

  reply	other threads:[~2022-03-18 12:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-16 23:29 iommufd dirty page logging overview Thanos Makatos
2022-03-16 23:50 ` Jason Gunthorpe
2022-03-18  9:23   ` Tian, Kevin
2022-03-18 12:41     ` Jason Gunthorpe [this message]
2022-03-18 15:06       ` Alex Williamson
2022-03-18 15:55         ` Jason Gunthorpe
2022-03-19  7:54       ` Tian, Kevin
2022-03-19  8:14       ` Tian, Kevin
2022-03-20  3:34       ` Tian, Kevin
2022-03-21 13:30         ` Jason Gunthorpe
2022-03-22  2:40           ` Tian, Kevin
2022-03-17 12:39 ` Joao Martins

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=20220318124108.GF11336@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=eric.auger@redhat.com \
    --cc=joao.m.martins@oracle.com \
    --cc=john.g.johnson@oracle.com \
    --cc=john.levon@nutanix.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=stefanha@redhat.com \
    --cc=thanos.makatos@nutanix.com \
    --cc=yi.l.liu@intel.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.