ACRN needs to trap the pm1a/pm1b written/read from VM0. So we
could know when should we put the system to S3.
We will have two path back to VM0:
- S3 enter/exit sucess. Will reset VM0 and jump to VM0 wakeup vec
with real mode
- S3 enter/exit failed. Will return to the next instruction of
pm1a/pm1b register writing. VM0 will read the pm1a/pm1b evt
register to check whether it's waked up or not.
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Emulate VM0 resume from S3 state:
- reset BSP of VM0
- set the BSP entry to saved VM0 wakeup vec and set BSP to real mode
- start BSP
To match trampoline_spinlock release on ACRN Sx resume path, acquire
trampoline_spinlock if ACRN Sx enter fails.
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
enter_s3 is main function for ACRN to enter S3 state with following
process:
- pause vm0
- save the wakeup vec of vm0 and set wakeup vec of ACRN. So
resume from S3 will jump to ACRN wakeup
- offline APs
- update the main entry of trampoline to resume entry. After BSP
is resume from S3, it will jump to resume entry instead of AP
startup routine
- turn off vmx
- suspend devices
- enter S3.
exit S3 with following process:
- release trampoline_spinlock which is hold in trampoline code
- resume devices
- enable vmx
- update the main entry of trampoline to AP startup routine.
- online APs.
The following operations will be resume vm0 which will be added
in next patch.
Signed-off-by: Zheng Gen <gen.zheng@intel.com>
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The S3 enter lowlevel routine saves the cpu context to memory
and enter S3 state
The S3 wakeup lowlevel routine restore cpu context and return.
Signed-off-by: Zheng Gen <gen.zheng@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Now, we only add native msr save/restore functions. The native power
related functions will be put to this file.
Signed-off-by: Zheng Gen <gen.zheng@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Yin Fengwei