[Intel-gfx] [PATCH] drm/i915/gem: Support discontiguous lmem object maps

Matthew Auld matthew.william.auld at gmail.com
Thu Jan 2 12:27:42 UTC 2020


On Thu, 2 Jan 2020 at 11:44, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>
> Quoting Matthew Auld (2020-01-02 11:39:41)
> > On Thu, 2 Jan 2020 at 10:38, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > >
> > > Create a vmap for discontinguous lmem objects to support
> > > i915_gem_object_pin_map().
> >
> > Yes, please.
> >
> > >
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Cc: Matthew Auld <matthew.auld at intel.com>
> > > ---
> >
> > [snip]
> >
> > > @@ -288,12 +284,28 @@ static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> > >                 pgprot = pgprot_writecombine(PAGE_KERNEL_IO);
> > >                 break;
> > >         }
> > > -       addr = vmap(pages, n_pages, 0, pgprot);
> > >
> > > -       if (pages != stack_pages)
> > > -               kvfree(pages);
> > > +       if (i915_gem_object_has_struct_page(obj)) {
> > > +               struct sgt_iter iter;
> > > +               struct page *page;
> > > +               pte_t **ptes = mem;
> > > +
> > > +               for_each_sgt_page(page, iter, sgt)
> > > +                       **ptes++ = mk_pte(page, pgprot);
> > > +       } else {
> > > +               const resource_size_t iomap = obj->mm.region->iomap.base;
> > > +               struct sgt_iter iter;
> > > +               dma_addr_t addr;
> > > +               pte_t **ptes = mem;
> > > +
> > > +               for_each_sgt_daddr(addr, iter, sgt)
> >
> > addr -= region.start; for poor old fake local-memory.
>
> Positive? I wasn't sure since we are using the physical address and not
> a mapping within the mapping?

I think so. It's 1:1 mapped so:

fake_lmem_start = 4G;
iomap = mappable_aperture_start;

daddr = fake_lmem_start + n;
n = daddr - fake_lmem_start;

io_addr = iomap + n;

>
> It's hard to tell, since so long as the address exists we can read/write
> to it, and only later pay the consequences of corrupting someone else's
> memory.

BAT results should tell us, where we write from the gpu and then read
from the cpu.

> -Chris


More information about the Intel-gfx mailing list