Re: userspace IO support
On 3/28/2024 9:21 PM, yfliu2008 wrote: > I am still trying to understand existing userland address envrionment in NuttX kernel mode, I saw the following regions defined in "arch/Kconfig": config ARCH_TEXT_VBASE, config ARCH_DATA_VBASE, config ARCH_HEAP_VBASE, config ARCH_SHM_VBASE, config ARCH_KMAP_VBASE, config ARCH_STACK_VBASE, config ARCH_PGPOOL_VBASE. I can understand most of above, except the "ARCH_KMAP_VBASE" thing. But it doesn't look like relating to UIO though. I added most of those definitions back in 2014. They are used in the addrenv logic for addrenv creation. ARCH_KMAP_VBASE was added later and is used in arch/risc-v/src/common/riscv_addrenv_pgmap.c There is inconsistent logic. For the older SAMA5, for example, all fixed virtual address are listed in header files under arch/arm/src/sama5/*_memorymap.h I think that the use of Kconfig variables is fine for major landmarks in the virtual address space, but a finer grained virtual memory map probably should go in a header file as offsets from the configurable VBASE addresses. Anything not dynamically allocated from the user heap or via mmap probably should be a constant offset. The user head allocations are already virtual, but not physically contiguous and hence, not useful for UIO.
Re:Re: userspace IO support
Gregory, thank you!I am still trying to understand existing userland address envrionment in NuttX kernel mode, I saw the following regions defined in "arch/Kconfig": config ARCH_TEXT_VBASEconfig ARCH_DATA_VBASEconfig ARCH_HEAP_VBASEconfig ARCH_SHM_VBASEconfig ARCH_KMAP_VBASEconfig ARCH_STACK_VBASEconfig ARCH_PGPOOL_VBASEI can understand most of above, except the "ARCH_KMAP_VBASE" thing. But it doesn't look like relating to UIO though. Regards,yf OriginalFrom:"Gregory Nutt"< spudan...@gmail.com >;Date:2024/3/29 10:37To:"dev"< dev@nuttx.apache.org >;Subject:Re: userspace IO supportOn 3/28/2024 8:23 PM, Gregory Nutt wrote:> ...>> On all platforms that I am aware of, the virtual address of the > framebuffer is just a configurable constant. This makes sense if the > framebuffer is in a fixed virtual address in every process. The kernel > can manage the virtual address space anyway that it likes. A fixed > virtual position for the framebuffer is a reasonable decision. More > logic is need to manage the virtual address space to handle things > like pthread stacks, heap, shared libraries, framebuffers, etc. The > logic and virtual memory layout in Linux is quite complex even though > all of these are at fixed virtual addresses in every process.pthread stacks have some particular complexities. First, their virtual address be aligned to a large value. Old versions of Linux that I worked with in the past aligned the pthread virtual addresses to 2 MByte. This permits TLS to work by simply ANDing an address (vs performing a system call).Right now, pthread stacks are malloc'ed and, as a result, cannot exploit this fast TLS access.Old versions of Linux supported an array of pthread stacks (hence, limiting the number of pthreads to something like 200). Each stack was 2MByte of virtual address. All fixed, constant virtual addresses.
Re: userspace IO support
On 3/28/2024 8:23 PM, Gregory Nutt wrote: ... On all platforms that I am aware of, the virtual address of the framebuffer is just a configurable constant. This makes sense if the framebuffer is in a fixed virtual address in every process. The kernel can manage the virtual address space anyway that it likes. A fixed virtual position for the framebuffer is a reasonable decision. More logic is need to manage the virtual address space to handle things like pthread stacks, heap, shared libraries, framebuffers, etc. The logic and virtual memory layout in Linux is quite complex even though all of these are at fixed virtual addresses in every process. pthread stacks have some particular complexities. First, their virtual address be aligned to a large value. Old versions of Linux that I worked with in the past aligned the pthread virtual addresses to 2 MByte. This permits TLS to work by simply ANDing an address (vs performing a system call). Right now, pthread stacks are malloc'ed and, as a result, cannot exploit this fast TLS access. Old versions of Linux supported an array of pthread stacks (hence, limiting the number of pthreads to something like 200). Each stack was 2MByte of virtual address. All fixed, constant virtual addresses.
Re: userspace IO support
On 3/28/2024 7:05 PM, yfliu2008 wrote: Yes the user land only use standard file operations like "mmap()/read()/write()/munmap()/ioctl()" etc to access the device memory and interruption status via the exposed device files like "/dev/uio3" etc. Sorry it took me so long to catch on. My original question was about things in Nuttx Kernel side to support implement the required "mmap()/munmap()" operations. It seems that we need: A way to mark the user address regions so that to distinguish free and in use mapped regions. We also need separate this space from existing user space regions like TEXT, DATA, HEAP, SHM etc as it is for UIO purposes. A way to set the user space mappings via "int up_addrenv_uio_map(va, pa, length, flags)" and the counter part. These mainly operates the MMU page table entries with proper flags. Add an UIO component in "drivers/uio/uio.c" which exposes the "int uio_register(path, paddr, length, irq)" method for BSP to use to instantiate the needed devices. My purpose wasn't about video display, but this is what I got from the "fb" example in kernel mode now: ... You might also want to look at the (fake) file mapping. It doesn't do much. ... Currently the video device driver returns physical address directly in the "mmap()", which should be mapped in the user space for kernel build however. The driver level should return the virtual address. The actual framebuffer driver is in drivers/video/fb.c. It is a character driver that is more-or-less an upper half for the lcd driver. It gets the "planeinfo" from the lcd driver getplaneinfo() method which includes the virtual address of the framebuffer (line 1184) and eventually returns that address with the offset in the fb_mmap method (line 1035). [The offset means something different in UIO] On all platforms that I am aware of, the virtual address of the framebuffer is just a configurable constant. This makes sense if the framebuffer is in a fixed virtual address in every process. The kernel can manage the virtual address space anyway that it likes. A fixed virtual position for the framebuffer is a reasonable decision. More logic is need to manage the virtual address space to handle things like pthread stacks, heap, shared libraries, framebuffers, etc. The logic and virtual memory layout in Linux is quite complex even though all of these are at fixed virtual addresses in every process. I would do the same. It is more efficient and guarantees no virtual address overlap. I am unsure if video display is a good use case for UIO but that is what I can test now with "rv-virt". It is not a bad case either. It does a lot of what you want to do.
Re: userspace IO support
This could actually be very interesting. mmap() really does all of the work. But notice that mmap() it is not passed any address information (other than a "suggested" mapped, user-space address). It also received an instance of the file descriptor of the driver. The Linux file_operations structure is here: https://elixir.bootlin.com/linux/latest/source/include/linux/fs.h#L1983 Notice that there is a mmap method in the file operations. So, mmap(), it seems, calls the mmap method on the driver which performs the user spacemapping of the device resource, much as you suggested in your original email. The mmap() offset field specifies which device resource to map. That actually sounds very elegant to me and meets all of my concerns: * The application cannot map any arbitrary kernel address to user space so the implementation is secure. * It uses the standard POSIX mmap() to accomplish the mapping. On 3/28/2024 3:01 PM, Gregory Nutt wrote: I found this document which describes the use cases for UIO in Linux: https://www.kernel.org/doc/html/v4.13/driver-api/uio-howto.html . They use mmap() to addess device memory: "|/dev/uioX| is used to access the address space of the card. Just use |mmap()| to access registers or RAM locations of your card." There is a paragraph with a little more info: https://www.kernel.org/doc/html/v4.13/driver-api/uio-howto.html#mmap-device-memory My only concerns here are: (1) We use POSIX/Linux compatibility in interface definitions and (2) We assure security of kernel resources. I am not sure how mmap() knows which kernel mappings are secure and which are insecure. But we would need to address that. If secure, standard interfaces are used, then I am supportive (and you can ignore many of my other comments which were just me fumbling to understand the proposal). On 3/28/2024 12:25 PM, Gregory Nutt wrote: A more interesting task would be to port NxLib to run on top of the existing NuttX NX Windows System: * https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629474 * https://cwiki.apache.org/confluence/display/NUTTX/NX+Graphics+Subsystem That would not be particularly easier, however. The NX Window System is purely a windowing system and does not provide any significant graphics support. X11, by comparison, is a complete graphics system and user libraries are really only needed to simplify the interfaces and to extend the graphics capabilities. You would have to come up with some way to provide the graphics capability in Nano-X not included in NX Windows. In the NX Windows world, graphics was intended to be provided by NxWidgets. That, however, is a work that was never really completed to production quality. There are also several window managers that use NX Windows and NxWidgets: NX and Twm4Nx. The latter is a TWM inspired window manager (but a unique C++ development).
Re: userspace IO support
I found this document which describes the use cases for UIO in Linux: https://www.kernel.org/doc/html/v4.13/driver-api/uio-howto.html . They use mmap() to addess device memory: "|/dev/uioX| is used to access the address space of the card. Just use |mmap()| to access registers or RAM locations of your card." There is a paragraph with a little more info: https://www.kernel.org/doc/html/v4.13/driver-api/uio-howto.html#mmap-device-memory My only concerns here are: (1) We use POSIX/Linux compatibility in interface definitions and (2) We assure security of kernel resources. I am not sure how mmap() knows which kernel mappings are secure and which are insecure. But we would need to address that. If secure, standard interfaces are used, then I am supportive (and you can ignore many of my other comments which were just me fumbling to understand the proposal). On 3/28/2024 12:25 PM, Gregory Nutt wrote: A more interesting task would be to port NxLib to run on top of the existing NuttX NX Windows System: * https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629474 * https://cwiki.apache.org/confluence/display/NUTTX/NX+Graphics+Subsystem That would not be particularly easier, however. The NX Window System is purely a windowing system and does not provide any significant graphics support. X11, by comparison, is a complete graphics system and user libraries are really only needed to simplify the interfaces and to extend the graphics capabilities. You would have to come up with some way to provide the graphics capability in Nano-X not included in NX Windows. In the NX Windows world, graphics was intended to be provided by NxWidgets. That, however, is a work that was never really completed to production quality. There are also several window managers that use NX Windows and NxWidgets: NX and Twm4Nx. The latter is a TWM inspired window manager (but a unique C++ development).
Re: userspace IO support
A more interesting task would be to port NxLib to run on top of the existing NuttX NX Windows System: * https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629474 * https://cwiki.apache.org/confluence/display/NUTTX/NX+Graphics+Subsystem That would not be particularly easier, however. The NX Window System is purely a windowing system and does not provide any significant graphics support. X11, by comparison, is a complete graphics system and user libraries are really only needed to simplify the interfaces and to extend the graphics capabilities. You would have to come up with some way to provide the graphics capability in Nano-X not included in NX Windows. In the NX Windows world, graphics was intended to be provided by NxWidgets. That, however, is a work that was never really completed to production quality. There are also several window managers that use NX Windows and NxWidgets: NX and Twm4Nx. The latter is a TWM inspired window manager (but a unique C++ development).
Re: Nano-x porting
On 3/28/2024 11:17 AM, Shijo George wrote: I was planning to port NanoX to NuttX as part of GSoC. Is anyone familiar with NanoX? Any suggestions and help would be much appreciated. Regards , Shijo george This will likely be a very difficult job. Nano-X is a complete X-11 replacement from the the level of the video, mouse/touchpad, and keyboard drivers and up. The first challenge will be getting all of the drivers working. I see that there there is a support for RTEMS in Nano-X (although it has not changed for 19 years). RTEMS is older RTOS and you should be able to search for occurrences of RTEMS in the repository. Each of those probably has a corresponding change needed for NuttX. RTEMS Drivers: https://github.com/ghaerr/microwindows/tree/master/src/drivers Nano-X is the kernel portion of the solution and is probably not so useful without the microwindows NxLib for user space support. See http://www.microwindows.org/ (from 2018) and https://github.com/ghaerr/nxlib . That hasn't been updated in years. NxLib runs on top of MS Windows, X Windows, or Nano-X. That former link includes references to NxLib and Nano-X documents from 2000. I see that you have already started discussions with people on the Nano-X team: https://github.com/ghaerr/microwindows/issues/85 Those are the right people that you need to talk to. No one on this list can really help you much other than with driver and architectural issues.
Nano-x porting
I was planning to port NanoX to NuttX as part of GSoC. Is anyone familiar with NanoX? Any suggestions and help would be much appreciated. Regards , Shijo george
Re: userspace IO support
On 3/28/2024 1:03 AM, yfliu2008 wrote: ... Have "up_addrenv_map(), up_addrenv_unmap()" alike interfaces added to encapsulate MMU mapping operations of different chip architectures. These are used by UIO component to a. As an architectural description it is confusing to understand what you see in user space and what you see in kernel space. Some of my responses may be incorrect because I am not sure what you are describing and I am probably just responding to buzzwords. For example, non-standard interfaces are fine if they are used only internally in the OS. None of the internal OS interfaces conform to any standard.
Re: userspace IO support
On 3/28/2024 8:21 AM, Gregory Nutt wrote: On 3/28/2024 1:03 AM, yfliu2008 wrote: Have UIO framework added which exposes an "uio_register_device()" interface to BSP so that to instantiate different UIO devices with specific device path, address range and IRQ data. Then userland apps can use standard file operation interfaces to access the UIO devices in a portable manner. We proabably can start with simpler devices with only one memory range and one IRQ. You are proposing that the application control the virtual address space? That is a really bad idea. The OS should (and does) control the virtual address space) One thing to be careful with is the security issue: No operation by an application should permit visibility of the kernel address space to an application. That would be a gaping security hole and must be avoided.
Re: userspace IO support
On 3/28/2024 1:03 AM, yfliu2008 wrote: Dear experts, I am wondering if we can have an Userspace IO alike component added to NuttX kernel? It can help exposing video frame buffers or neural network accelerators alike devices to user land services. Often kernel has little to do with such devices and their management are offloaded to user land. I think that this is already fully supported. Video frame buffers are matured have been in use by NX and LVGL for years. General shared memory device support is also provided by standard POSIX shared memory interfaces. Guess that we may need following things in NuttX kernel: Have "CONFIG_ARCH_UIO_VBASE" alike Kconfig items added to give virtual addresse for devices memory in user space. Have "up_addrenv_map(), up_addrenv_unmap()" alike interfaces added to encapsulate MMU mapping operations of different chip architectures. These are used by UIO component to a. I am VERY opposed to adding non-standard, non-portable application interfaces. That is forbidden in a POSIX OS (unless there is no option). Standard shard memory access is already supported as are interfaces for all devices that have dedicated memory to be shared. If we allow non-standard application interfaces into the we are, in the long run, destroying the OS. Have UIO framework added which exposes an "uio_register_device()" interface to BSP so that to instantiate different UIO devices with specific device path, address range and IRQ data. Then userland apps can use standard file operation interfaces to access the UIO devices in a portable manner. We proabably can start with simpler devices with only one memory range and one IRQ. You are proposing that the application control the virtual address space? That is a really bad idea. The OS should (and does) control the virtual address space) I am unsure if some one have some considerations or there is better route in NuttX kernel mode for such things? If so, please feel free to teach me. Comments are highly welcomed. A kernel-based solution that uses only POSIX interfaces (like shared memory interfaces or IOCTLs) would be preferable.
