Re: user_to_phys() without mmap?

On Mon, 16 Jul 2007 17:50:29 +0200 Rainer Weikusat <rweikusat@xxxxxxxxxxx> wrote:
| phil-news-nospam@xxxxxxxx writes:
|> On Mon, 16 Jul 2007 14:46:24 +0200 Rainer Weikusat <rweikusat@xxxxxxxxxxx> wrote:
|> | phil-news-nospam@xxxxxxxx writes:
|> |> On Sun, 15 Jul 2007 00:20:45 +0200 Rainer Weikusat <rweikusat@xxxxxxxxxxx> wrote:
|> |> | Neil Steiner <neil.steiner@xxxxxx> writes:
|> |> |> I'm trying to use a framebuffer from user space (think plain video
|> |> |> ram, not some PCI or AGP video card), but mmap'ing from kernel space
|> |> |> into user space is causing large latencies and unsightly artifacts.
|> |> |> It appears that anything written into the mmap'ed user memory is in
|> |> |> fact being copied into kernel space.
|> |> |
|> |> | Theoretically, this could probably be implemented with help of the
|> |> | MMU and some 'weird' fault handling, but I don't think someone would
|> |> | take the trouble, because it seems pretty useless. The /dev/mem driver
|> |> | certainly doesn't do this. Only the MMU will interfere accesses to
|> |> | virtual memory locations from user space, except for faults caused by
|> |> | this accesses.
|> |>
|> |> I tried to map the video buffer into user space some time ago and I did
|> |> find that what was mapped was not the actual physical memory of the video
|> |> card, but just some memory apparently allocated by a driver in the kernel
|> |> which was then periodically copied from that memory into the real physical
|> |> memory.
|> |
|> | Which driver? That should be easy to determine.
|>
|> The basic console driver used for text and framebuffer modes.
|
| So you weren't mmaping some hardware framebuffer to begin with but the
| virtual framebuffer associated with one of the virtual consoles,
| right?

Both. I was hoping the kernel would switch translations so that what was
mapped in VM for the framebuffer would be changed over to literally access
the hardware when that console was switched to be the one displayed.

This isn't a hard concept to understand. I just don't know if there any
big showstoppers in the kernel or hardware (like the segment tables). It
would be similar to activating and de-activating pages (part of swapping).

When the virtual console to be displayed is changed by whatever means is
changing it, then something like these steps would happen:

1. Remove segment table entries for the mappings of the old console
to a state similar to "swapped out". If a process tries to access
that data during the copying, it gets blocked like it would be for
a page to swap in.

2. Copy data from the hardware buffer to memory allocated to save the
old virtual console.

3. Set up the segment table entries for the mappings of the old console
to point to the memory location where the contents was saved.

4. If any processes were blocked on these mappings, unblock them.

5. Remove segment table entries for the mappings of the new console
to a state similar to "swapped out". If a process tries to access
that data during the copying, it gets blocked like it would be for
a page to swap in.

6. Copy data from the memory allocated to save the new virtual console
into the hardware buffer.

7. Set up the segment table entries for the mappings of the new console
to point to the hardware buffer memory locations.

8. If any processes were blocked on these mappings, unblock them.

This is just a memory mappable variation of what virtual text consoles are
doing now, anyway. It just extends to graphical content (more content)
and provides for mappability (via a raw virtual console device node).
Appropriate locks will be needed, especially on MP systems.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-07-16-1546@xxxxxxxx |
|------------------------------------/-------------------------------------|
.

Relevant Pages

  • Re: size_t or int for malloc-type functions?
    ... Some go as high as 3GB with special boot ... RedHat has a special Linux kernel that gives just under 4GB of user address space; a bit of kernel space is still required to keep syscalls working, ... It's mainly used by database folks, who should be moving to AMD64 now anyways (with its 2^51 bytes of user space, currently). ... of like the old extended/expanded memory hacks in the DOS days. ...
    (comp.lang.c)
  • Re: [swsusp] separate snapshot functionality to separate file
    ... >> Split does not prevent you from doing the cleanups. ... Kernel needs to use get_user, ... > memory directly from the used space. ... > not be visible to the user space at all. ...
    (Linux-Kernel)
  • Re: Virtual memory - user space kernel space
    ... It depends upon the total size of kernel code and static data. ... 1G/3G division in virutal memory is nothing but a set of pointers to ... User space pointers has to go via MMU to get the location in physical ... you bumble virtual and physical memory. ...
    (comp.os.linux.development.system)
  • Re: [BUG] kernel crash with CONFIG_SPARSEMEM on my ia32 box
    ... > I have one machine with 4G memory and 1G pci memory hole ... I compiled kernel with CONFIG_SPARSEMEM ... > Enabling fast FPU save and restore... ... > Console: colour VGA+ 80x25 ...
    (Linux-Kernel)
  • Re: [swsusp] separate snapshot functionality to separate file
    ... Kernel needs to use get_user, ... >> memory directly from the used space. ... >> not be visible to the user space at all. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)