LPAR (Logical Partition Address Region)

The Cell architecture uses a technique known as Logical Partioning to execute and isolate different OS regions to prevent them from interfering with one another. Testing using Hypervisor calls such as lv1_allocate_memory and lv1_map_device_mmio_region has revealed the algorithm used to calculate the addresses of logical partition regions. This knowledge could prove useful when examining regions allocated by the Hypervisor as the logical partition address can be used to determine the size of the allocated region and indicate with respect to the uptime of the OS as to when the allocation took place. More information on the lpar is also available from lv1_query_logical_partition_address_region_info.

A logical partition address is derived from the requested region size and a counter that is incremented with each allocation. The address itself comprises two parts, the Base and the Counter.

Address = 0xbbccccccc000, where bb = Base and ccccccc = Counter

Allocating consecutive regions of the same size returns a consistent pattern of addresses - each is offset from the previous by the size of the region rounded up to the nearest power of two. Furthermore, allocating regions of differing sizes results in addresses that indicate that the allocation algorithm is based upon an incrementing counter multiplied by the rounded region size. This counter is common for all allocations, independent of their size.

Addresses are not (initially) reused, as freeing a region before the next allocation of the same size returns the next address in the sequence. Interestingly, when the upper limit of an address region is reached (e.g. 0x33fffffff000 for 0×1000 byte allocations) the address rolls back to the initial base address (e.g. 0×300000000000), though the addresses of any regions that have not been released are NOT reused, suggesting that the algorithm also keeps track of allocated regions.

The address base is determined by the size of the allocated region:

The allocator also appears to be memory agnostic - addresses for DDR allocation are in sequence with XDR allocations.

Here is a simple calculator that can convert between size and counter values to addresses and vice versa.

Note that the calculator does not perform any error checking for invalid values and will generate incorrect values for rolled over addresses (though is not very likely that these will occur in regular usage). The code is slightly convoluted as Javascript does not handle 64 bit numbers well.

The value of the allocation counter on a fully boot Linux system is relatively small (depending on which drivers are enabled). By constructing lpars for counter value from 0 to current, and for each power of two of region size (12-28), and calling lv1_query_logical_partition_address_region_info on the contructed lpar, it is possible to determine all the lpars allocated so far by the hypervisor and their characteritics. Indeed, calls to lv1_query_logical_partition_address_region_info on unallocated or freed lpars will return LV1_NO_ENTRY (-6).

This algorithm was used a minimalistic Linux system, with network only and hotplug memory restricted to 96MB. Then device drivers were loaded one at a time (USB, storage, lpm, sound, graphics). It reveals the following lpars are used:

The SPU shadow registers are accessed read-only by the Linux kernel, and the lpar access_right have a value of 1 instead of 3 for all other lpars tested. It suggests the access_right field is a bitfield, with bit 0 for read-access and bit 1 for write-access.

Read access time is in CPU cycles (from mftb() * 40), measured on the first dword of the lpar, averaged over 1 million loops.

Allocating via lv1_allocate_memory creates additional entries, with flags reflecting the flags parameter, though only flags 2**0-3 are accepted for this call.