Hello, openvz developers! I'm interested in framebuffer vritualization for openvz (2.6.32 and 3.10). Such thing was developed in CELLS project http://systems.cs.columbia.edu/projects/cells/
There was some work done in Paralles http://habrahabr.ru/company/parallels/blog/174211/ Some tips are needed regarding dev_ns. Is this ns already present in openvz? PS: cells kernel is based on linux 3.1.0 Commit Message ======================== dev_ns: adopt the framebuffer subsystem Adds device namespace logic to the framebuffer subsystem. Isolate framebuffer state between device namespaces, and multiplex access to hardware state between the virtual framebuffers. Associate with each device namespace a shadow, virtual 'struct fb_info' (vinfo) and a backing buffer, for each registered hardware framebuffer. Access from an active (foreground) device namespace is passed-through directly to the underlying device. Access from a passive (background) device namespace is directed to the virtal fb_info. The backing buffer is used for mmap-ed memory in passive namespace, so any drawing occurs to the backing buffer instead of to the real driver. When the active namespace changes, perform a context-switch and swap such mappings: remap memory previously in foreground to the backing buffer, and from background to the underlying device. The contents of the framebuffer is saved and restored in (from) the bacgkround (active) backing buffer, respectively. Changelog: [16-Aug-13] v1 - initial version Change-Id: I355650abc45b6f0c6c66fd86f91e3cfd8e50b4f7 Signed-off-by: Oren Laadan <[email protected]> ======================== +config FB_DEV_NS 75 +» bool "Enable FB device namespace" 76 +» depends on FB 77 +» depends on DEV_NS 78 +» select FB_SYS_FOPS 79 +» select FB_CFB_FILLRECT 80 +» select FB_CFB_COPYAREA 81 +» select FB_CFB_IMAGEBLIT 82 +» default n 83 +» ---help--- 84 +» Allow per-namespace virtual framebuffers by mulplexing access to 85 +» the hardware framebuffer. This is intended for containers with 86 +» device namespace (see COFNIG_DEV_NS) interactive use case, where 87 +» there is a single "foreground" container and possibly multiple 88 +» "background" containers. 89 + 90 +» It provdies virtualization for the framebuffer subsystem. When 91 +» activated, each container has a private view of the framebuffer, 92 +» but only the foreground container has pass-through access to the 93 +» hardware framebuffer, while the others see a virtual framebuffer. 94 + 95 +» If unsure, say N. ======== dev_ns: introduce device namespaces Introduce device namespaces: The idea with a device namespace comes from the Android-Cells project where namespaces are utilized to create a container-like environment on Linux, only where there's a notion of an 'active' namespace and all other namespaces are inactive. In such a case only processes residing within the active device namespace should communicate with actual devices, where processes inside inactive containers should be able to communicate gracefully with the device driver, but not the device. Changelog: [16-Aug-2013] v1 - initial version Change-Id: I143a84272e230089f7e5db58d02fb9b1f2df9ee1 Signed-off-by: Oren Laadan <[email protected]> Signed-off-by: Amir Goldstein <[email protected]> ============== +config DEV_NS 854 +» bool "Device Namespaces (EXPERIMENTAL)" 855 +» default n 856 +» depends on PID_NS 857 +» help 858 +» Support device driver namespaces. This allows drivers to multiplex 859 +» access to its physical or logical resources. A device namespace has 860 +» a one-to-one relationship with a PID namespace currentlly, but this 861 +» will likely change in the future. ============= _______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
