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 20:02:13 -0300	[thread overview]
Message-ID: <20220502230213.GU8364@nvidia.com> (raw)
In-Reply-To: <20220502220447.GT8364@nvidia.com>

On Mon, May 02, 2022 at 07:04:47PM -0300, Jason Gunthorpe wrote:
> > Ah great, implicit limitations not reported to the user that I hadn't
> > even guessed!  How does a user learn about any limitations in the
> > number of ranges or size of each range?
> 
> There is some limit of number of ranges and total aggregate address
> space, you think we should report rather than try-and-fail?
> 
> I guess total address space and total number of ranges is easy to
> report, but I don't quite know what userspace will do with it?

Actually, I recall now, the idea was that the driver would sort this
out.

So, userspace would pass in whatever ranges it wanted and if the
device could do only. say 4, then the driver would merge adjacent
ranges till there were only 4 - and limit each range to any device
limit there may be and so on and so forth.

If the result was unfittable then it fails and the only thing
userspace can do is try with less.

So, if userspace wants to do 'minimal + extra for hotplug' then on
failure it should try 'minimal' and on failure of that give up
completely.

Then we don't have to try and catalog all the weird device choices we
might need into some query function.

Yishahi, this concept should be called out in the documentation, and
we probably need some core code to pull the ranges into an interval
tree and validate they are non-overlapping and so forth

Jason

  reply	other threads:[~2022-05-02 23:02 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
2022-05-02 19:58     ` Alex Williamson
2022-05-02 22:04       ` Jason Gunthorpe
2022-05-02 23:02         ` Jason Gunthorpe [this message]
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=20220502230213.GU8364@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