On Wed, 31 Aug 2011, Konrad Rzeszutek Wilk wrote: > Attached is an RFC set of patches to enable S3 to work with the Xen hypervisor. > > The relationship that Xen has with Linux kernel is symbiotic. The Linux > kernel does the ACPI "stuff" and tells the hypervisor to do the low-level > stuff (such as program the IOAPIC, setup vectors, etc). The realm of > ACPI S3 is more complex as we need to save the CPU state (and Intel TXT > values - which the hypervisor has to do) and then restore them. > > The major difficulties we hit was with 'acpi_suspend_lowlevel' - which tweaks > a lot of lowlevel values and some of them are not properly handled by Xen. > Liang Tang has figured which ones of them we trip over (read below) - and he > suggested that perhaps we can provide a registration mechanism to abstract > this away. > > So the attached patches do exactly that - there are two entry points > in the ACPI. > > 1). For S3: acpi_suspend_lowlevel -> .. lots of code -> acpi_enter_sleep_state > 2). For S1/S4/S5: acpi_enter_sleep_state > > The first naive idea was of abstracting away in the 'acpi_enter_sleep_state' > function the tboot_sleep code so that we can use it too. And low-behold - it > worked splendidly for powering off (S5 I believe) > > For S3 that did not work - during suspend the hypervisor tripped over when > saving cr8. During resume it tripped over at restoring the cr3, cr8, idt, > and gdt values. > > What do you guys think? One thought is to use the paravirt interface to > deal with cr3, cr8, idt, gdt for suspend/resume case.. But that is a lot > of extra 'if' in the paravirt code - which the callback registration would > effectively do the same thing as the paravirt - except at a higher level. > > Thoughts? I think there are no doubts about the fact that this approach produces cleaner code than using the pvop interface for dealing with cr3, cr8, etc. Also, having seen the original xen acpi implementation in 2.6.18, I want to add that you did a _very_ good job with this series. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
