On Mon, Mar 18, 2013 at 9:32 PM, YoungJun Cho <yj44.cho@xxxxxxxxxxx> wrote: > > On Mar 19, 2013 9:55 AM, "Rob Clark" <robdclark@xxxxxxxxx> wrote: >> >> On Mon, Mar 18, 2013 at 8:00 PM, YoungJun Cho <yj44.cho@xxxxxxxxxxx> >> wrote: >> > >> > On Mar 19, 2013 3:01 AM, "Rob Clark" <robdclark@xxxxxxxxx> 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. oh, ouch.. maybe there is someway to reset the 2d core, and move on? If no, then I guess cmdstream checking is required. If there is some way to recover, that seems like a generally good thing to implement.. BR, -R >> 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx >> >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> _______________________________________________ >> >> dri-devel mailing list >> >> dri-devel@xxxxxxxxxxxxxxxxxxxxx >> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> _______________________________________________ >> dri-devel mailing list >> dri-devel@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
