Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
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;

  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