[PATCH] ACPI cleanup's and enablement for Xen ACPI S3 [v4].

From: Konrad Rzeszutek Wilk
Date: Fri Dec 16 2011 - 17:39:37 EST


Attached is an [v4] set of patches to enable S3 to work with the Xen hypervisor
and also do some cleanups. Posting just before holidays so that when folks are
tired of unwrapping presents, drinking eggnog, etc, they can read some
exciting patches!

Changes since v3: [http://lkml.org/lkml/2011/11/15/340]:
- Redid the acpi_os_prepare_sleep fnc per Rafael's suggestions.
- Fixed compile issues on other platforms, various config options.
Changes since v2: [https://lkml.org/lkml/2011/9/29/408]
- Moved tboot_sleep out to the osl.c code.
- Dropped some patches.
since the RFC posting [http://comments.gmane.org/gmane.linux.acpi.devel/50701]:
- Per review comments added: __unused__ attribute, support for PM1A/B if more than 16-bit,
copyright/license.
- Added support for PHYSDEVOP_restore_msi_ext call.

The first two patches can be considered independently as cleanup - they move
the tboot_sleep out of the ACPI code and move it in the OS part. That is
the only OSPM code changes done.

The more complex ones are in the ACPI x86 code. I was not sure how to
post the patches so I grouped them in "functionality" parts.

1). Use the acpi_os_prepare_sleep to register a variant of it. The reason
for the need for this is explained in more details below. The patches are:

[PATCH 1/7] x86, acpi, tboot: Have a ACPI os prepare sleep instead
[PATCH 2/7] tboot: Add return values for tboot_sleep
[PATCH 3/7] xen/acpi/sleep: Enable ACPI sleep via the

2). Expand x86_msi_ops. Every time we resume, we end up calling write_msi_irq
to resume the MSI vectors. But when using Xen, we would write the MSI
vectors using the other x86_msi_ops - hence we expand the x86_msi_ops
indirection mechanism to take resume in account. The paches are:

[PATCH 4/7] x86: Expand the x86_msi_ops to have a restore MSIs.
[PATCH 5/7] xen/pci: Utilize the restore_msi_irqs hook.

3). Make acpi_suspend_lowlevel be a function pointer instead of a function.
Details of why we want to omit the lowlevel values is explained below.
Originally I was thinking that perhaps doing it via a registration
function would be better? But not sure what folks leanings are
in this case. The patches are:

[PATCH 6/7] x86/acpi/sleep: Provide registration for
[PATCH 7/7] xen/acpi/sleep: Register to the acpi_suspend_lowlevel a

Details of what I said in the first postings:

The Xen ACPI S3 functionality requires help from the Linux kernel. 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). Naturally do it correctly
the Xen hypervisor must be programmed with correct values that are extracted
as part of parsing the ACPI.

The ACPI code used during suspend is mostly all in hwsleep.c and there is one
particular case where 'hwsleep.c' is calling in the tboot.c code. This is replaced
by making the call go through the OS part of the ACPI code. The reason for
doing this is two fold: 1) cleanup, 2) for Xen case, it needs to make a hypercall
so that the hypervisor can write the PM1A/PM1B bits.

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. The reason for all of this is that Linux does not talk to the
BIOS directly - instead it simply walks through the necessary ACPI methods
and then issues hypercall to Xen which then further completes the remaining
suspend steps.

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.

When I posted the RFC, the feedback I got was to use a higher upper
interface to make the call to the hypervisor. Instead of doing it at the
lower pv-ops case for cr3, cr8, idt, gdt, etc. The code is much nicer
this way, I've to say.

Anyhow, please take a look!

The patches are also located at

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/acpi-s3.v7

arch/x86/include/asm/acpi.h | 2 +-
arch/x86/include/asm/pci.h | 9 +++++
arch/x86/include/asm/x86_init.h | 1 +
arch/x86/kernel/acpi/boot.c | 7 ++++
arch/x86/kernel/acpi/sleep.c | 4 +-
arch/x86/kernel/acpi/sleep.h | 2 +
arch/x86/kernel/tboot.c | 9 +++--
arch/x86/kernel/x86_init.c | 1 +
arch/x86/pci/xen.c | 27 ++++++++++++++
arch/x86/xen/enlighten.c | 3 ++
drivers/acpi/acpica/hwsleep.c | 10 ++++--
drivers/acpi/osl.c | 24 +++++++++++++
drivers/acpi/sleep.c | 2 +
drivers/pci/msi.c | 29 ++++++++++++++-
drivers/xen/Makefile | 2 +-
drivers/xen/acpi.c | 62 +++++++++++++++++++++++++++++++++
include/acpi/acexcep.h | 1 +
include/linux/acpi.h | 10 +++++
include/linux/tboot.h | 1 -
include/xen/acpi.h | 72 +++++++++++++++++++++++++++++++++++++++
include/xen/interface/physdev.h | 7 ++++
21 files changed, 272 insertions(+), 13 deletions(-)

Konrad Rzeszutek Wilk (5):
tboot: Add return values for tboot_sleep
x86/acpi/sleep: Provide registration for acpi_suspend_lowlevel.
xen/acpi/sleep: Enable ACPI sleep via the __acpi_os_prepare_sleep
xen/acpi/sleep: Register to the acpi_suspend_lowlevel a callback.
x86: Expand the x86_msi_ops to have a restore MSIs.

Tang Liang (2):
x86, acpi, tboot: Have a ACPI os prepare sleep instead of calling tboot_sleep.
xen: Utilize the restore_msi_irqs hook.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/