Hi all,
I have one question about the ownership change for AHCI.
Based on ahci spec v1.3 http://download.csdn.net/detail/berg65123068/1866484 page 21 there are registers definition for BIOS/OS Handoff Control and Status.
Bit2: "SMI on OS Ownership Change enable"(SOOE) - This bit, when set to 1, enables an SMI when the OOC bit is set to 1
This means if OOC(OS Ownership Change) is 1 and SOOE is 1 then an SMI is generated...(the former is the status bit and the latter is the enable bit)
My question is: does this SMI is generated by hardware ? Or by system software/BIOS ? I am also wondering why these registers are required ?
* As I know, SMI is a special interrupt and system software or BIOS have specific way to trigger an SMI...
Thanks !
About the ownership change for AHCI...
Re: About the ownership change for AHCI...
Based on section 10.6 in ahci spec, I think SMI should be generated by HBA, not by BIOS or driver.
But the corresponding SMI handler should be prepared by BIOS first.
The purpose of this handoff mechanism is to coordinate the ownership of HBA between BIOS and the system software(driver) if BIOS or Option ROM execute some background I/O <- OS(driver) does not know...
I am wondering if this mechanism is used on current platforms ?
* because as I knew BIOS or Option ROM do not execute "background" I/Os when OS owned HBA...
But the corresponding SMI handler should be prepared by BIOS first.
The purpose of this handoff mechanism is to coordinate the ownership of HBA between BIOS and the system software(driver) if BIOS or Option ROM execute some background I/O <- OS(driver) does not know...
I am wondering if this mechanism is used on current platforms ?
* because as I knew BIOS or Option ROM do not execute "background" I/Os when OS owned HBA...
Re: About the ownership change for AHCI...
liaoo wrote:Based on section 10.6 in ahci spec, I think SMI should be generated by HBA, not by BIOS or driver.
But the corresponding SMI handler should be prepared by BIOS first.
The purpose of this handoff mechanism is to coordinate the ownership of HBA between BIOS and the system software(driver) if BIOS or Option ROM execute some background I/O <- OS(driver) does not know...
I am wondering if this mechanism is used on current platforms ?
* because as I knew BIOS or Option ROM do not execute "background" I/Os when OS owned HBA...
Yep,liaoo wrote:Based on section 10.6 in ahci spec, I think SMI should be generated by HBA, not by BIOS or driver.
But the corresponding SMI handler should be prepared by BIOS first.
For the computer nowadays(no matter dektop, server, laptop.etc) that supports power management should contains this mechanism.liaoo wrote:I am wondering if this mechanism is used on current platforms ?
Both BIOS, OS can trigger SMI so that cpu will save its current execution context and run the codes in special places, it is mainly used for hardware check, (memory check, other controller 's check)
Re: About the ownership change for AHCI...
We tested some PCs and used protocol analyzer trying to capture the memory access targeting the BIOS Hand/off registers BUT found nothing. Thus we think this mechanism is not used extensively...(I believe these PCs support power management...)