6

I was reading through this page on how sleep states work in Windows and I was intrigued by the reset vector. My current understanding is that;

When the system is in S2/S3, the processor is fully powered down, caches are lost and the bus is at least stopped, if not entirely unpowered. The contents of RAM are preserved to allow a quick resume.

On resume, the processor reads the address stored at the reset vector (on x86, that's 0xFFFFFFF0) which is commonly mapped to ROM. It jumps to the address it's just read and begins executing.

Since it's ROM, I assume the memory can't be readily written and so must remain semi-constant (excluding BIOS flashes, etc)

So, the processor powers up, reads an address from ROM, jumps to that address and begins execution (presumably a POST or other initialisation).

At some point along the way, it needs to jump back to whatever it was executing before sleeping.

Where is the address to resume from stored and what causes the processor to look there?

Improve this question
3
  • well, S2/S3 drops all CPU context for previously active threads, so it doesn't resume any tasks that were executing at the time it went to sleep. This is the main distinction between S2/3 and Hibernation (S4).
    – Frank Thomas
    Commented Nov 24, 2015 at 20:13
  • @FrankThomas I don't think that's required for S2. Do you have a reference? This page says In these states (S1-S3), volatile memory is kept refreshed to maintain the system state. Some components remain powered so the computer can wake from input from the keyboard, LAN, or a USB device. I'm aware that Win8 logs off the user before hibernating (S4) instead of doing a real shutdown, so it can resume quickly (ending session means less memory to write to disk = faster)
    – Basic
    Commented Nov 24, 2015 at 20:18
  • 1
    @FrankThomas We've both edited at the same time. I'm aware CPU caches/context are lost, RAM should be preserved (although processes may or may not be terminated beforehand) but how do we get from the address at the reset vector to a running system without doing a boot? It may not resume all threads but somewhere along the way it hands control to the OS.
    – Basic
    Commented Nov 24, 2015 at 20:21

1 Answer 1

Reset to default
3

The code at the 0xFFFF0 reset vector for the legacy BIOS can be changed by the OS to be directed to RAM and not flash using Cbo SAD PAM configuration registers in the L3 cache controller accessible through PCIe config space on one of the bus 0 devices. The SAD is probably hard coded to redirect 0xFFFFFFF0 to IIO (I.e. DMI) however – I don't know what would happen if you were to configure a DRAM_RULE (MMCFG / DRAM / NXM) over the top of it.

It's the BIOS that does this when it boots up (the legacy BIOS shadows itself to the same address by initially redirecting writes to RAM and not reads), and not the OS, because that's what knows what device is on bus 0 and what register offset configures these SADs for the CPU models compatible with that BIOS Version. The BIOS abstracts this away for the OS using ACPI (for instance the OS doesn't need to know where the PCIEXBAR is for that specific CPU, it can just look in the MCFG ACPI table).

In this case the kernel only needs to write the resume code address to the firmware waking vector in the FACS pointed to by the Firmware Control field in the FADT ACPI table. The 0xFFFFFFF0 reset vector doesn't need to be changed because the ACPI status register check happens in code reached by the reset vector. See more. Of further interest. Although the reset vector is probably not 0xFFFFFFF0, it might be the microcode that verifies the startup ACM and loads microcode updates. I'm guessing so because power would have been lost to the microcode patch SRAM.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .