public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Yishai Hadas <yishaih@nvidia.com>,
	kvm@vger.kernel.org, maorg@nvidia.com, cohuck@redhat.com,
	kevin.tian@intel.com, joao.m.martins@oracle.com, cjia@nvidia.com,
	kwankhede@nvidia.com, targupta@nvidia.com,
	shameerali.kolothum.thodi@huawei.com, eric.auger@redhat.com
Subject: Re: [PATCH RFC] vfio: Introduce DMA logging uAPIs for VFIO device
Date: Mon, 2 May 2022 16:25:41 -0300	[thread overview]
Message-ID: <20220502192541.GS8364@nvidia.com> (raw)
In-Reply-To: <20220502130701.62e10b00.alex.williamson@redhat.com>

On Mon, May 02, 2022 at 01:07:01PM -0600, Alex Williamson wrote:

> > +/*
> > + * Upon VFIO_DEVICE_FEATURE_SET stop device DMA logging that was started
> > + * by VFIO_DEVICE_FEATURE_DMA_LOGGING_START
> > + */
> > +#define VFIO_DEVICE_FEATURE_DMA_LOGGING_STOP 4
> 
> This seems difficult to use from a QEMU perspective, where a vfio
> device typically operates on a MemoryListener and we only have
> visibility to one range at a time.  I don't see any indication that
> LOGGING_START is meant to be cumulative such that userspace could
> incrementally add ranges to be watched, nor clearly does LOGGING_STOP
> appear to have any sort of IOVA range granularity.  

Correct, at least mlx5 HW just cannot do a change tracking operation,
so userspace must pre-select some kind of IOVA range to monitor based
on the current VM configuration.

> Is userspace intended to pass the full vCPU physical address range
> here, and if so would a single min/max IOVA be sufficient?  

At least mlx5 doesn't have enough capacity for that. Some reasonable
in-between of the current address space, and maybe a speculative extra
for hot plug.

Multi-range is needed to support some arch cases that have a big
discontinuity in their IOVA space, like PPC for instance.

> I'm not sure how else we could support memory hotplug while this was
> enabled.

Most likely memory hot plug events will have to take a 'everything got
dirty' hit during pre-copy - not much else we can do with this HW.

> How does this work with IOMMU based tracking, I assume that if devices
> share an IOAS we wouldn't be able to exclude devices supporting
> device-level tracking from the IOAS log.

Exclusion is possible, the userspace would have to manually create
iommu_domains and attach devices to them with the idea that only
iommu_domains for devices it wants to track would have dma dirty
tracking turned on.

But I'm not sure it makes much sense, if the iommu will track dirties,
and you have to use it for another devices, then it is unlikely there
will be a performance win to inject a device tracker as well.

In any case the two interfaces are orthogonal, I would not expect
userspace to want to track with both, but if it does everything does
work.

> Is there a bitmap size limit?  

Joao's code doesn't have a limit, it pulls user pages incrementally as
it goes.

I'm expecting VFIO devices to use the same bitmap library as the IOMMU
drivers so we have a consistent reporting.

Jason

  reply	other threads:[~2022-05-02 19:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-01 12:33 [PATCH RFC] vfio: Introduce DMA logging uAPIs for VFIO device Yishai Hadas
2022-05-02 19:07 ` Alex Williamson
2022-05-02 19:25   ` Jason Gunthorpe [this message]
2022-05-02 19:58     ` Alex Williamson
2022-05-02 22:04       ` Jason Gunthorpe
2022-05-02 23:02         ` Jason Gunthorpe
2022-05-03 11:46           ` Joao Martins
2022-05-03 11: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=20220502192541.GS8364@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=cjia@nvidia.com \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=joao.m.martins@oracle.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=maorg@nvidia.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=targupta@nvidia.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox