cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

deferred_io.rst (3064B)


      1===========
      2Deferred IO
      3===========
      4
      5Deferred IO is a way to delay and repurpose IO. It uses host memory as a
      6buffer and the MMU pagefault as a pretrigger for when to perform the device
      7IO. The following example may be a useful explanation of how one such setup
      8works:
      9
     10- userspace app like Xfbdev mmaps framebuffer
     11- deferred IO and driver sets up fault and page_mkwrite handlers
     12- userspace app tries to write to mmaped vaddress
     13- we get pagefault and reach fault handler
     14- fault handler finds and returns physical page
     15- we get page_mkwrite where we add this page to a list
     16- schedule a workqueue task to be run after a delay
     17- app continues writing to that page with no additional cost. this is
     18  the key benefit.
     19- the workqueue task comes in and mkcleans the pages on the list, then
     20  completes the work associated with updating the framebuffer. this is
     21  the real work talking to the device.
     22- app tries to write to the address (that has now been mkcleaned)
     23- get pagefault and the above sequence occurs again
     24
     25As can be seen from above, one benefit is roughly to allow bursty framebuffer
     26writes to occur at minimum cost. Then after some time when hopefully things
     27have gone quiet, we go and really update the framebuffer which would be
     28a relatively more expensive operation.
     29
     30For some types of nonvolatile high latency displays, the desired image is
     31the final image rather than the intermediate stages which is why it's okay
     32to not update for each write that is occurring.
     33
     34It may be the case that this is useful in other scenarios as well. Paul Mundt
     35has mentioned a case where it is beneficial to use the page count to decide
     36whether to coalesce and issue SG DMA or to do memory bursts.
     37
     38Another one may be if one has a device framebuffer that is in an usual format,
     39say diagonally shifting RGB, this may then be a mechanism for you to allow
     40apps to pretend to have a normal framebuffer but reswizzle for the device
     41framebuffer at vsync time based on the touched pagelist.
     42
     43How to use it: (for applications)
     44---------------------------------
     45No changes needed. mmap the framebuffer like normal and just use it.
     46
     47How to use it: (for fbdev drivers)
     48----------------------------------
     49The following example may be helpful.
     50
     511. Setup your structure. Eg::
     52
     53	static struct fb_deferred_io hecubafb_defio = {
     54		.delay		= HZ,
     55		.deferred_io	= hecubafb_dpy_deferred_io,
     56	};
     57
     58The delay is the minimum delay between when the page_mkwrite trigger occurs
     59and when the deferred_io callback is called. The deferred_io callback is
     60explained below.
     61
     622. Setup your deferred IO callback. Eg::
     63
     64	static void hecubafb_dpy_deferred_io(struct fb_info *info,
     65					     struct list_head *pagelist)
     66
     67The deferred_io callback is where you would perform all your IO to the display
     68device. You receive the pagelist which is the list of pages that were written
     69to during the delay. You must not modify this list. This callback is called
     70from a workqueue.
     71
     723. Call init::
     73
     74	info->fbdefio = &hecubafb_defio;
     75	fb_deferred_io_init(info);
     76
     774. Call cleanup::
     78
     79	fb_deferred_io_cleanup(info);