Date: Wed, 16 Jul 2003 16:07:40 +0200 From: Joshua LeVasseur <jtl-freebsd@bothan.net> To: freebsd-ppc@freebsd.org Subject: PowerPC system ISA limitations Message-ID: <DC832D88-B796-11D7-8EBA-000393DB44E8@bothan.net>
next in thread | raw e-mail | index | archive | help
According to the PowerPC programming environments manual, certain operations are to be avoided while virtual addressing is enabled. But to me, the wording in the respective locations of the manual is ambiguous. I was wondering if anyone knew more specifics regarding three situations: 1. The hashed page table: From section 7.6 of the v2.0 PEM (from IBM), "If page table search operations are performed automatically by the hardware, they are performed using physical addresses and as if the memory access attribute bit M=1 (memory coherency enforced in hardware). If the software performs the page table search operations, the accesses must be performed in real addressing mode (MSR[DR] = 0); this additionally guarantees that M=1." What is meant by software searches? A search performed by firmware, or the operating system kernel when the processor doesn't implement hardware searching? Or is this a generic page hash lookup by one's operating system kernel? If a generic page hash lookup by one's kernel, why is real mode necessary? If I use a BAT register to back the code and data used for searching the page hash, is that sufficient for leaving virtual addressing enabled? I have tested the situation where I use BAT registers while manipulating the page hash with virtual addressing enabled (a BAT register maps the page hash, another BAT for kernel code, and another BAT for kernel data). It executes correctly (or at least visibly). Perhaps side effects are implementation dependent (i.e. my processors were constructed such that they support searches with virtual addressing enabled) ... In section 7.6.3.2, the process for modifying a page table entry is described. Yet it doesn't mention whether or not the processor should be in real mode. Modification isn't the same as performing a search ... or is it? 2. Exception processing In section 6.2 of the v2.0 PEM, "Note: In some implementations, every instruction fetch when MSR[IR] = 1, and every data acess requiring address translation when MSR[DR] = 1, may modify SRR0 and SRR1." Is this just another way of saying that address translation may raise an exception, and thus store exception state? Or is this describing strange behavior, such as writing random data into these registers without raising an exception? If there is the chance of changing these registers without a corresponding exception, then an obvious use for rfi is lost: switching from virtual mode to physical mode while jumping to the physical mode instruction pointer. One can fill-out srr0 and srr1 while virtual addressing is enabled and handled by BAT registers (and external interrupts + decrementer exceptions are disabled), and then rfi. 3. Cache aliases In section 7.6.3 (of IBM's PEM v2.0) in regards to modifying the virtual address of a PTEG entry, "If the virtual address is being changed to a different address within the same hash class (primary or secondary), the following flow suffices: [psuedo code skipped] ... In this example, if the new address is not a cache synonym (alias) of the old address, care must be taken to also flush (or invalidate) from an on-chip cache any cache synonyms for the page. Thus, a temporary virtual address that is a cache synonym with the page whose PTE is being modified can be assigned and then used for the cache flushing (or invalidation)." This sounds like the manual describes a cache which uses virtual, or psuedo-virtual tags. I thought PowerPC uses physical cache tags. The implications of the paragraph are nasty though ... an OS may unmap a page, map the same physical page to a new address within the same PTEG much later, and then cause side effects due to invalid cache state. Perhaps the behavior is processor dependent? Or must every PowerPC kernel flush a page from the cache when unmapping the page? Thanks for any guidance, Josh
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DC832D88-B796-11D7-8EBA-000393DB44E8>