[PATCH 0/7] Consider G2D hardware restrictions.

YoungJun Cho yj44.cho at samsung.com
Mon Mar 18 18:32:21 PDT 2013


On Mar 19, 2013 9:55 AM, "Rob Clark" <robdclark at gmail.com> wrote:
>
> On Mon, Mar 18, 2013 at 8:00 PM, YoungJun Cho <yj44.cho at samsung.com>
wrote:
> >
> > On Mar 19, 2013 3:01 AM, "Rob Clark" <robdclark at gmail.com> wrote:
> >>
> >> Btw, what is the hw response to invalid input (ie. bottom>top, invalid
> >> size, etc)?
> >>
> >
> > Unfortunately the IOMMU page fault is happened. So we need some codes
for
> > protecting kernel.
>
> hmm, a page fault is not necessarily a problem.. do you have some way
> to know which userspace client the the fault is associated with (I
> assume so, unless you have some way to have multiple contexts active
> at one time), and some sane way to recover?
>

When IOMMU page fault is occured, kernel oops is generated now because it
is unrecoverable.

> I only ask this because, for an xorg/exa perspective, you can have a
> large # of blits that effect a small # of pixels, so minimizing
> per-blit overhead can be important for performance.  (otoh, if you
> already have to do some cmdstream checking in the kernel to ensure
> security, maybe it doesn't add much overhead for a few extra checks.
> Depends on whether it can all be done in one pass and without
> additional load (LDR) instructions from the cmdstream buffer (which is
> presumably not in a cached buffer)
>

Right, performance is important.
We already have checked all command lists for buffer addresses security and
it is done in one pass.
And this patch gathers additional data for HW restriction during previous
checking routine.

Thank you
Best regards YJ

> BR,
> -R
>
> > Thank you~
> > Best regards YJ
> >
> >> Ie. if it will just ignore the blit or raise an error irq which can be
> >> handled sanely, it could be ok to avoid the overhead of the cmdstream
> >> checking in the kernel.  The kernel part really just needs to ensure
> >> that userspace can't cause security problems (read/write access to
> >> non-gfx-buffers, or lock up the system, that sort of thing).  It
> >> doesn't need to guarantee that the results are sensible.
> >>
> >> BR,
> >> -R
> >>
> >> On Wed, Mar 13, 2013 at 5:03 AM, Inki Dae <inki.dae at samsung.com> wrote:
> >> > This patch set checks the contents of g2d command list from user
> >> > is valid or not according to G2D hardware restrictions. For now,
> >> > G2D driver wasn't considered for them properly.
> >> >
> >> > For this, this patch set includes relevant code cleaups, fixups
> >> > and adds a new function to get buffer size to the gem to be
> >> > accessed by G2D dma.
> >> >
> >> > Inki Dae (1):
> >> >   drm/exynos: Add a new function to get gem buffer size
> >> >
> >> > YoungJun Cho (6):
> >> >   drm/exynos: Fix error routine to getting dma addr.
> >> >   drm/exynos: clear node object type at gem unmap
> >> >   drm/exynos: Fix G2D core mulfunctioning issue
> >> >   drm/exynos: Clean up some G2D codes for readability
> >> >   drm/exynos: Deal with g2d buffer info more efficiently
> >> >   drm/exynos: Check g2d cmd list for g2d restrictions
> >> >
> >> >  drivers/gpu/drm/exynos/exynos_drm_g2d.c |  381
> >> > ++++++++++++++++++++++++++-----
> >> >  drivers/gpu/drm/exynos/exynos_drm_gem.c |   21 ++
> >> >  drivers/gpu/drm/exynos/exynos_drm_gem.h |    5 +
> >> >  3 files changed, 349 insertions(+), 58 deletions(-)
> >> >
> >> > --
> >> > 1.7.4.1
> >> >
> >> > _______________________________________________
> >> > dri-devel mailing list
> >> > dri-devel at lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/44176a3a/attachment.html>


More information about the dri-devel mailing list