From: Nirmoy Das <nirmoy.das@linux.intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Cc: Andi Shyti <andi.shyti@kernel.org>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Chris Wilson <chris.p.wilson@linux.intel.com>,
Lionel Landwerlin <lionel.g.landwerlin@intel.com>,
Michal Mrozek <michal.mrozek@intel.com>,
Nirmoy Das <nirmoy.das@intel.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v2] drm/i915/gt: Report full vm address range
Date: Thu, 21 Mar 2024 23:11:00 +0100 [thread overview]
Message-ID: <674ea24b-b7a0-477b-bd04-f951c5581d3d@linux.intel.com> (raw)
In-Reply-To: <20240321151726.207866-1-andi.shyti@linux.intel.com>
Hi Andi,
On 3/21/2024 4:17 PM, Andi Shyti wrote:
> Commit 9bb66c179f50 ("drm/i915: Reserve some kernel space per
> vm") has reserved an object for kernel space usage.
>
> Userspace, though, needs to know the full address range.
>
> In the former patch the reserved space was substructed from the
> total amount of the VM space. Add it back when the user requests
> the GTT size through ioctl (I915_CONTEXT_PARAM_GTT_SIZE).
>
> Fixes: 9bb66c179f50 ("drm/i915: Reserve some kernel space per vm")
> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> Cc: Michal Mrozek <michal.mrozek@intel.com>
> Cc: Nirmoy Das <nirmoy.das@intel.com>
> Cc: <stable@vger.kernel.org> # v6.2+
> Acked-by: Michal Mrozek <michal.mrozek@intel.com>
> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> ---
> Hi,
>
> Just proposing a different implementation that doesn't affect
> i915 internally but provides the same result. Instead of not
> substracting the space during the reservation, I add it back
> during the ioctl call.
>
> All the "vm->rsvd.vma->node.size" looks a bit ugly,
Yes, this need document and also vm->total should be vm->total and may
be we should have
vm->usable which will be used by kernel internal and return vm->total.
For me, I am fine with the kernel change as long as UMD is aware/fine of
side-effect if
UMD ended up using the reserved page. Basically we need to document this
well :)
Also may be we should limit this reserving page only on platform where
it is required ?
Regards,
Nirmoy
> but that's
> how it is. Maybe a comment can help to understand better why
> there is this addition.
>
> I kept the Ack from Michal and Lionel, because the outcome from
> userspace perspactive doesn't really change.
>
> Andi
>
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 81f65cab1330..60d9e7fe33b3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -2454,7 +2454,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data,
> case I915_CONTEXT_PARAM_GTT_SIZE:
> args->size = 0;
> vm = i915_gem_context_get_eb_vm(ctx);
> - args->value = vm->total;
> + args->value = vm->total + vm->rsvd.vma->node.size;
> i915_vm_put(vm);
>
> break;
next prev parent reply other threads:[~2024-03-21 22:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-21 15:17 [PATCH v2] drm/i915/gt: Report full vm address range Andi Shyti
2024-03-21 21:35 ` ✗ Fi.CI.BAT: failure for drm/i915/gt: Report full vm address range (rev3) Patchwork
2024-03-21 22:11 ` Nirmoy Das [this message]
2024-03-22 4:05 ` ✗ Fi.CI.BAT: failure for drm/i915/gt: Report full vm address range (rev4) Patchwork
2024-03-27 10:38 ` ✗ Fi.CI.BAT: failure for drm/i915/gt: Report full vm address range (rev5) Patchwork
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=674ea24b-b7a0-477b-bd04-f951c5581d3d@linux.intel.com \
--to=nirmoy.das@linux.intel.com \
--cc=andi.shyti@kernel.org \
--cc=andi.shyti@linux.intel.com \
--cc=andrzej.hajda@intel.com \
--cc=chris.p.wilson@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lionel.g.landwerlin@intel.com \
--cc=michal.mrozek@intel.com \
--cc=nirmoy.das@intel.com \
--cc=stable@vger.kernel.org \
/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