Intel Rapid Start support

The firmware level feature of "Intel Rapid Start" ("iRST") works for Ubuntu as long as the appropriate partition is present and it's enabled in the firmware. Rapid Start will wake the machine up from S3, dump the contents of RAM to a special partition and put the system into S4. When the machine wakes up the firmware loads all the stuff from that partition back into RAM and returns to the OS. It's akin to a hybrid suspend+hibernate solution but has hardware level support but is more reliable and capable of being faster. Additionally, iRST hibernate works even if zram/compcache is used.

Some platforms are able to configure/enable settings for it in the firmware, while others are not. Kernel 3.11 is introducing a kernel module for modifying the settings for this, which is especially useful for platforms that can't modify this any other way other than from Windows.

The kernel module will only load if the firmware offers support for iRST, and the firmware will only offer iRST if:
* An SSD is present
* Ivy Bridge or newer/Intel 7 Series chipset support (very rare on Sandy Bridge/Intel 6 Series chipset, not present previously)
* Dedicated partition == to size of memory type 0x84 in MBR layout or GUID D3BFE2DE-3DAF-11DF-BA-40-E3A556D89593 in GPT layout.
* BIOS support (would be exposed through ACPI if the above requirements are met)

There are a few places that could be expanded to make this experience better now starting with Kernel 3.11:
1) In the power management GUI, if the iRST module is loaded, offer to toggle the different settings the module adds a sysfs interface for. Turning on/off Rapid Start and configuring the timeout after suspend to kick in Rapid Start.

2) In the installer, the default automatic recipes should create this partition if possible, or at least offer a toggle for enabling. Currently, it should only kick in when 8GB or less RAM is present, the installation target is an SSD and it's an Intel Ivy Bridge chipset or newer. We should have a better method to determine whether a system supports iRST if at all possible.
 - This works for MBR or GPT, but the situation is tricky with MBR because of the limited number of possible partitions. For the installer, we might want to only offer the option of using iRST if installing in UEFI mode and using GPT.
 - We need a reliable way to detect this in advance of partitioning so that we're not spending 8GB extra disk for a partition that can't/won't be used
- Provide an installer hook to force enablement, so that OEMs can invoke that on the appropriate hardware.
- There's concern about reserving too much disk space for swap and hibernate. We would like to move to swap files regardless, but haven't done this yet for unrelated reasons.

3) If iRST is in use, default to a modified behavior for "hibernate" whereby, instead of using software hibernation, the OS instead sets the iRST timer to 0 and puts the computer to sleep.
 - For sleep, use a sensible timeout when firmware will write out RAM to SSD. This "sleep" will functionally be hybrid sleep. There is disagreement about whether a separate "hibernate" option should be exposed to the user, whereby "hibernate" is actually "let the firmware do iRST hibernate immediately after we put the system into S3".

4) What do we do differently if the user has an encrypted disk?
* what to do if encrypted swap is enabled - Section 2.6 of the Intel Rapid Start Technology Deployment Guide v1.0 (link below) covers how iRST handles different kinds of disk encryption. We can either disable iRST if software disk encryption is used or provide a way to flush and re-enter credentials on resume.
 * rapid start can be enabled *if* the disk is password protected, *or* homedir encryption (encrypted swap?) is not enabled.

5) What optimizations can be done in-OS to leverage iRST for faster hibernate/thaw?
Investigate the requirements within Linux for providing better reporting of "in-use" memory prior to sleep. Per Intel, "During the transition to the Sleep state, the service flushes the Standby and Modified memory pages to reduce the amount of memory reported as “in-use.” This can considerably reduce the amount of data that needs to be transferred to the SSD, resulting in improved resume time. Another function provided by the service is optimizing the amount of active pages that need to be written to the SSD. This feature is up to the OEM to enable. Similar to the above example, the service will flush the non-critical active pages during the Sleep transition. Again, this improves
resume performance but also reduces the required SSD partition size." <http://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/responsiveness-technologies-brief.pdf>

6) Newer implementations of iRST have optional support for hibernating to a partition that is smaller than the amount of memory in the system using an "Active Page Threshold" feature (per section 2.5.2 of the Intel Rapid Start Technology Deployment Guide).
 - How can we find out from the firmware that this is supported, and if it is, what is the threshold for a given system's configuration?

The Intel Rapid Start Technology Deployment Guide covers the technology's functionality: http://downloadmirror.intel.com/22647/eng/Intel%20Rapid%20Start%20Technology%20Deployment%20Guide%20v1.0.pdf