Editing Hypervisor Reverse Engineering

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 8,561: Line 8,561:
==HV Calls==
==HV Calls==


===lv1_gpu_memory_allocate===
===lv1_gpu_context_allocate===
 
* LV1 supports 16 memory handles simultaneously.
* LV1 uses a bitmap to manage GPU VRAM.
* The bitmap is located in LV1 memory, 4 double words.
* Each bit corresponds to 1MB VRAM, 256bit = 256MB VRAM.
* 2MB at the top of VRAM are preallocated as you can see below.
 
<pre>
<memory handle> = 0x5a5a5a5a xor <memory handle index>
</pre>
 
====Memory Context Object====
 
offset 0x8 - memory handle (4 bytes)
 
offset 0x10 - VRAM LPAR start address (8 bytes)
 
offset 0x18 - VRAM LPAR end address (8 bytes)
 
====Test====
 
* The offset of bitmap could be different on your system because it's allocated dynamically.
* '''First 9MB of VRAM were allocated by ps3fb Linux driver.'''
 
Before allocating VRAM:
<pre>
glevand@debian-hdd:~$ sudo dd if=/dev/ps3ram bs=1 count=$((0x20)) skip=$((0x1f85b0)) | hexdump -C
00000000  00 00 00 00 00 00 01 ff  00 00 00 00 00 00 00 00  |.......ÿ........|
00000010  00 00 00 00 00 00 00 00  c0 00 00 00 00 00 00 00  |........À.......|
</pre>
 
After allocating 32 MB VRAM:
<pre>
glevand@debian-hdd:~$ sudo dd if=/dev/ps3ram bs=1 count=$((0x20)) skip=$((0x1f85b0)) | hexdump -C
00000000  00 00 01 ff ff ff ff ff  00 00 00 00 00 00 00 00  |...ÿÿÿÿÿ........|
00000010  00 00 00 00 00 00 00 00  c0 00 00 00 00 00 00 00  |........À.......|
</pre>


===lv1_gpu_context_allocate===
%r4 - flags


* Register %r4 is flags.
* '''Found the place in LV1 where LV1 sets IO page size for GART memory mapping. We could patch it and set to 4KB. That would make a lot of things easier for RSX developers on Linux.'''
* '''Found the place in LV1 where LV1 sets IO page size for GART memory mapping. We could patch it and set to 4KB. That would make a lot of things easier for RSX developers on Linux.'''
* 1MB pages make RSX driver for Linux hard to implement because allocating 1Mb contiguous memory chunk on Linux is very very hard especially on a system with only 256MB and which was running for some time.
* 1MB pages make RSX driver for Linux hard to implement because allocating 1Mb contiguous memory chunk on Linux is very very hard.
 
* LV1 supports 16 contexts simultaneously.
* LV1 has an array of context pointers.
* Each context has an index and a handle. The handle is derived from the index of the context.
 
<pre>
<context handle> = 0x55555555 xor <context index>
</pre>
 
* Thats why first created context will have handle 0x55555555.
 
====Context Object====
 
offset 0x8 - handle (4 bytes)
 
offset 0x48 - IO page size, valid range is 4kB, 64KB and 1MB (8 bytes)


====Flags====
====Flags====


'''0x2 - tells LV1 to use 64KB pages for GART memory mapping else LV1 uses 1MB pages'''
'''0x2 - tells LV1 to use 64KB pages for GART memory mapping else LV1 uses 1MB pages'''
===lv1_gpu_context_iomap===
* Internally uses lv1_put_iopte function
* IO page size is the one set during lv1_gpu_context_allocate
* IO address space id is 0x0. IO id is 0x1.


===lv1_gpu_context_attribute===
===lv1_gpu_context_attribute===
Line 8,710: Line 8,650:


* '''This attribute is NOT available on 3.15 LV1 e.g. but on 3.41 it's implemented.'''
* '''This attribute is NOT available on 3.15 LV1 e.g. but on 3.41 it's implemented.'''
=====Cursor Function 1=====
<pre>
lv1_gpu_context_attribute(context handle, 0x10d, 0x1, 0x1, 0x0, 0x0)
</pre>


====Attribute 0x300====
====Attribute 0x300====
Line 8,734: Line 8,668:


=====Unbind Zcull=====
=====Unbind Zcull=====
====Attribute 0x601====
* Copies data from GART memory to VRAM.
* LV1 uses internally the FIFO command buffer passed by ps3fb driver with lv1_gpu_context_iomap.
FIFO commands:
<pre>
0x0004C184
0xFEED0001
0x0004C198
0x313371C3
0x00046300
0x0000000A
for ()
{
    for ()
    {
        0x0004630C
        <param>
        0x00046304
        <param>
        0x0024C2FC
        0x00000001
        0x00000003
        0x00000003
        <param1>
        <param2>
        <param3>
        <param4>
        0x00010000
        0x00010000
        0x0001C400
        <param1>
        <param2>
        <param3>
        0x00000000
    }
}
0x00040110
0x00000000
</pre>


==FIFO Command Buffer==
==FIFO Command Buffer==
Line 9,087: Line 8,972:
* GART memory region is a memory region in System Memory but accessible by RSX through GART [http://dri.freedesktop.org/wiki/GART].
* GART memory region is a memory region in System Memory but accessible by RSX through GART [http://dri.freedesktop.org/wiki/GART].
* GameOS calls it '''Main Memory'''.
* GameOS calls it '''Main Memory'''.
* '''Problem: lv1_gpu_context_iomap supports ONLY 1MB and 64kB pages'''
* '''Problem: lv1_gpu_context_iomap supports ONLY 1MB pages'''
* Size of system memory objects mapped into GPU address space should be either multiple of 1MB which means wasting lots of RAM and we don't have enough of it anyways. This solution is NOT suitable.
* Size of system memory objects mapped into GPU address space should be either multiple of 1MB which means wasting lots of RAM and we don't have enough of it anyways. This solution is NOT suitable.
* Or place several GART memory objects into 1 MB page and map it. That would mean we have to use memory manager for each 1MB page.
* Or place several GART memory objects into 1 MB page and map it. That would mean we have to use memory manager for each 1MB page.
Line 9,171: Line 9,056:


* Nouveau driver implements DRM fences with REF control register. See '''nouveau_fence.c:nouveau_fence_new'''.
* Nouveau driver implements DRM fences with REF control register. See '''nouveau_fence.c:nouveau_fence_new'''.
* Newer Nvidia chips support semaphores. Nouveau driver uses semaphores for fences if they are supported.
* libgcm functions '''SetWriteCommandLabel''' and '''SetWaitLabel''' use semaphores.
* '''SetWriteCommandLabel''' releases semaphore and '''SetWaitLabel''' acquires semaphore.
* Semaphores are placed in VRAM. Nouveau driver creates a small VRAM heap for semaphores. See '''nouveau_fence.c:nouveau_fence_channel_init'''.


====IOCTLs====
====IOCTLs====
Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)

Templates used on this page:

Retrieved from "http://www.psdevwiki.com/ps3/Hypervisor_Reverse_Engineering"