Edited to add your actual answer:
Protected Mode Software Architecture
Tom Shanley
Addison-Wesley Professional (March 16, 1996)
ISBN-10: 020155447X
ISBN-13: 978-0201554472
googlebook, amazon
My answer
Have you looked at "Understanding the Linux Kernel," 3rd Edition? It's available via Safari, and it's probably a good place to start for the OS side of things -- I don't think it gives you nitty-
gritty details, but it's an excellent guide that would probably put the linux kernel source and architecture-specific stuff into context. The following chapters give you the narrative you're asking for from the kernel side ("relationship between the hardware and the OS when an interrupt or context-switch occurs"):
- Chapter 3: Processes
- Chapter 4: Interrupts and Exceptions
- Chapter 7: Process Scheduling
Understanding the Linux Kernel, 3rd Ed.
Daniel P. Bovet; Marco Cesati
Publisher: O'Reilly Media, Inc.
Pub. Date: November 17, 2005
Print ISBN-13: 978-0-596-00565-8
Print ISBN-10: 0-596-00565-2
Safari, Amazon
My recommendation is a book like this, with the linux source code and the intel manuals and a full fridge of beer, and you'll be off and running.
A brief snippet from Chapter 3: Processes, to whet your appetite:
3.3.2. Task State Segment
The 80×86 architecture includes a specific segment type called the Task State Segment (TSS), to store hardware contexts. Although Linux doesn't use hardware context switches, it is nonetheless forced to set up a TSS for each distinct CPU in the system. This is done for two main reasons:
- When an 80×86 CPU switches from User Mode to Kernel Mode, it fetches the address of the Kernel Mode stack from the TSS (see the sections "Hardware Handling of Interrupts and Exceptions" in Chapter 4 and "Issuing a System Call via the sysenter Instruction" in Chapter 10).
- When a User Mode process attempts to access an I/O port by means of an in or out instruction, the CPU may need to access an I/O Permission Bitmap stored in the TSS to verify whether the process is allowed to address the port.
More precisely, when a process executes an in or out I/O instruction in User Mode, the control unit performs the following operations:
- It checks the 2-bit IOPL field in the eflags register. If it is set to 3, the control unit executes the I/O instructions. Otherwise, it performs the next check.
- It accesses the tr register to determine the current TSS, and thus the proper I/O Permission Bitmap.
- It checks the bit of the I/O Permission Bitmap corresponding to the I/O port specified in the I/O instruction. If it is cleared, the instruction is executed; otherwise, the control unit raises a "General protection " exception.
The tss_struct structure describes the format of the TSS. As already mentioned in Chapter 2, the init_tss array stores one TSS for each CPU on the system. At each process switch, the kernel updates some fields of the TSS so that the corresponding CPU's control unit may safely retrieve the information it needs. Thus, the TSS reflects the privilege of the current process on the CPU, but there is no need to maintain TSSs for processes when they're not running.
Another potential reference in the same vein is this one, which does have a lot more x86-specific stuff, and you might benefit a bit from the contrast w/ PowerPC.
Linux® Kernel Primer, The: A Top-Down Approach for x86 and PowerPC Architectures
Claudia Salzberg Rodriguez; Gordon Fischer; Steven Smolski
Publisher: Prentice Hall
Pub. Date: September 19, 2005
Print ISBN-10: 0-13-118163-7
Print ISBN-13: 978-0-13-118163-2
Safari, Amazon
Finally, Robert Love's Linux Kernel Development, 3rd Edition, has a pretty thorough description of context switching, though it may be redundant with the above. It's a pretty fantastic resource.