Quoting Fernando Pacheco (2019-04-19 18:14:21)
>
> On 4/19/19 12:14 AM, Chris Wilson wrote:
> > Quoting Fernando Pacheco (2019-04-19 00:31:48)
> >> - /* Trim the GGTT to fit the GuC mappable upper range (when enabled).
> >> - * This is easier than doing range restriction on the fly, as we
> >> - * currently don't have any bits spare to pass in this upper
> >> - * restriction!
> >> - */
> >> - if (USES_GUC(dev_priv)) {
> >> - ggtt->vm.total = min_t(u64, ggtt->vm.total, GUC_GGTT_TOP);
> >> - ggtt->mappable_end =
> >> - min_t(u64, ggtt->mappable_end, ggtt->vm.total);
> >> - }
[snip
> It is unlikely, but should there be a check in case GUC_GGTT_TOP exceeds vm.total and
> adjust the start accordingly? Or should we let this bail? GEM_BUG_ON?
If GUC_GGTT_TOP is outside the range of vm.total, that should give us a
bogus address for the drm_mm_reserve_node, and that should fail. That
seems reasonable, if we can't support the guc with the current GGTT
setup we probably do want to bail and get it fixed (as something would
be very wrong with the GGTT probe, one presumes).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
