Date: 17 Jul 2003 00:34:29 +1000 From: Benno Rice <benno@FreeBSD.org> To: Joshua LeVasseur <jtl-freebsd@bothan.net> Cc: freebsd-ppc@freebsd.org Subject: Re: PowerPC system ISA limitations Message-ID: <1058366069.782.12.camel@ratchet.jeamland.net> In-Reply-To: <DC832D88-B796-11D7-8EBA-000393DB44E8@bothan.net> References: <DC832D88-B796-11D7-8EBA-000393DB44E8@bothan.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-Lk5sy5KT/NWoJBgXPfWm Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2003-07-17 at 00:07, Joshua LeVasseur wrote: > According to the PowerPC programming environments manual, certain=20 > operations are to be avoided while virtual addressing is enabled. But=20 > to me, the wording in the respective locations of the manual is=20 > ambiguous. I was wondering if anyone knew more specifics regarding=20 > three situations: >=20 > 1. The hashed page table: > From section 7.6 of the v2.0 PEM (from IBM), "If page table search=20 > operations are performed automatically by the hardware, they are=20 > performed using physical addresses and as if the memory access=20 > attribute bit M=3D1 (memory coherency enforced in hardware). If the=20 > software performs the page table search operations, the accesses must=20 > be performed in real addressing mode (MSR[DR] =3D 0); this additionally=20 > guarantees that M=3D1." >=20 > What is meant by software searches? A search performed by firmware, or=20 > the operating system kernel when the processor doesn't implement=20 > hardware searching? Or is this a generic page hash lookup by one's=20 > operating system kernel? If a generic page hash lookup by one's=20 > kernel, why is real mode necessary? If I use a BAT register to back=20 > the code and data used for searching the page hash, is that sufficient=20 > for leaving virtual addressing enabled? Hardware page table lookups are an optional feature in PowerPC, at least in the original spec (not Book E which is the 64-bit version and specifies a very different MMU). If the implementation doesn't provide hardware table lookup then the OS has to provide it by providing fault handlers for DTLB and ITLB misses. These handlers have to abide by the restrictions listed. > I have tested the situation where I use BAT registers while=20 > manipulating the page hash with virtual addressing enabled (a BAT=20 > register maps the page hash, another BAT for kernel code, and another=20 > BAT for kernel data). It executes correctly (or at least visibly). =20 > Perhaps side effects are implementation dependent (i.e. my processors=20 > were constructed such that they support searches with virtual=20 > addressing enabled) ... See above. > In section 7.6.3.2, the process for modifying a page table entry is=20 > described. Yet it doesn't mention whether or not the processor should=20 > be in real mode. Modification isn't the same as performing a search=20 > ... or is it? The kernel could have the page tables mapped in at a virtual address. > 2. Exception processing > In section 6.2 of the v2.0 PEM, "Note: In some implementations, every=20 > instruction fetch when MSR[IR] =3D 1, and every data acess requiring=20 > address translation when MSR[DR] =3D 1, may modify SRR0 and SRR1." >=20 > Is this just another way of saying that address translation may raise=20 > an exception, and thus store exception state? Or is this describing=20 > strange behavior, such as writing random data into these registers=20 > without raising an exception? If there is the chance of changing these=20 > registers without a corresponding exception, then an obvious use for=20 > rfi is lost: switching from virtual mode to physical mode while jumping=20 > to the physical mode instruction pointer. One can fill-out srr0 and=20 > srr1 while virtual addressing is enabled and handled by BAT registers=20 > (and external interrupts + decrementer exceptions are disabled), and=20 > then rfi. I think it just says what it says. In some implementations you can't rely on SRR0 and SRR1 being consistant when address translations are in effect. This means that if you're going to re-enable address translation in an exception handler, you really want to save SRR0 and SRR1 first, but then that's a good idea anyway since if you take another exception you're going to lose them. If you really want to do a virtual to physical jump, you might want to use sc instead. > 3. Cache aliases > In section 7.6.3 (of IBM's PEM v2.0) in regards to modifying the=20 > virtual address of a PTEG entry, "If the virtual address is being=20 > changed to a different address within the same hash class (primary or=20 > secondary), the following flow suffices: [psuedo code skipped] ... In=20 > this example, if the new address is not a cache synonym (alias) of the=20 > old address, care must be taken to also flush (or invalidate) from an=20 > on-chip cache any cache synonyms for the page. Thus, a temporary=20 > virtual address that is a cache synonym with the page whose PTE is=20 > being modified can be assigned and then used for the cache flushing (or=20 > invalidation)." >=20 > This sounds like the manual describes a cache which uses virtual, or=20 > psuedo-virtual tags. I thought PowerPC uses physical cache tags. >=20 > The implications of the paragraph are nasty though ... an OS may unmap=20 > a page, map the same physical page to a new address within the same=20 > PTEG much later, and then cause side effects due to invalid cache=20 > state. Perhaps the behavior is processor dependent? Or must every=20 > PowerPC kernel flush a page from the cache when unmapping the page? This one I'm not so sure on. I think the PowerPC spec may not specify what sort of cache is used, but I may be wrong. --=20 Benno Rice benno@FreeBSD.org --=-Lk5sy5KT/NWoJBgXPfWm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQA/FWJ1XjRwWofFmQkRAteuAJ4yPxKNC/1/jyocWy/K59i83AKgAQCeMto7 xUQTMNF5WiXAas9EINo0xmc= =we0u -----END PGP SIGNATURE----- --=-Lk5sy5KT/NWoJBgXPfWm--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1058366069.782.12.camel>