Re: [Xen-devel] [PATCH v3 1/3] acpi: Call acpi_os_prepare_sleep hook in reduced hardware sleep path

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, Jul 24, 2013 at 11:14:06AM -0400, Ben Guthro wrote:
> 
> 
> On 07/24/2013 10:38 AM, Moore, Robert wrote:
> > I haven't found a high-level description of "acpi_os_prepare_sleep", 
> > perhaps I missed it.
> > 
> > Can someone point me to the overall description of this change and why it 
> > is being considered?
> 
> Hi Bob,
> 
> For this series, the v6 of this series does a decent job of what it is
> trying to accomplish:
> https://lkml.org/lkml/2013/7/1/205
> 
> However, I recognize that this does not really describe *why*
> acpi_os_prepare_sleep is necessary to begin with. For that, we need to
> go back a little more.
> 
> The summary for the series that introduced it is a good description, of
> the reasons it is necessary:
> http://lkml.indiana.edu/hypermail/linux/kernel/1112.2/00450.html
> 
> In summary though - in the case of Xen (and I believe this is also true
> in tboot) a value inappropriate for a VM (which dom0 is a special case
> of) was being written to cr3, and the physical machine would never come
> out of S3.
> 
> This mechanism gives an os specific hook to do something else down at
> the lower levels, while still being able to take advantage of the large
> amount of OS independent code in ACPICA.

It might be also prudent to look at original 'hook' that was added by
Intel in the Linux code to support TXT:


commit 86886e55b273f565935491816c7c96b82469d4f8
Author: Joseph Cihula <joseph.cihula@xxxxxxxxx>
Date:   Tue Jun 30 19:31:07 2009 -0700

    x86, intel_txt: Intel TXT Sx shutdown support
    
    Support for graceful handling of sleep states (S3/S4/S5) after an Intel(R) 
TXT launch.
    
    Without this patch, attempting to place the system in one of the ACPI sleep
    states (S3/S4/S5) will cause the TXT hardware to treat this as an attack and
    will cause a system reset, with memory locked.  Not only may the subsequent
    memory scrub take some time, but the platform will be unable to enter the
    requested power state.
    
    This patch calls back into the tboot so that it may properly and securely 
clean
    up system state and clear the secrets-in-memory flag, after which it will 
place
    the system into the requested sleep state using ACPI information passed by 
the kernel.
    
     arch/x86/kernel/smpboot.c     |    2 ++
     drivers/acpi/acpica/hwsleep.c |    3 +++
     kernel/cpu.c                  |    7 ++++++-
     3 files changed, 11 insertions(+), 1 deletion(-)
    
    Signed-off-by: Joseph Cihula <joseph.cihula@xxxxxxxxx>
    Signed-off-by: Shane Wang <shane.wang@xxxxxxxxx>
    Signed-off-by: H. Peter Anvin <hpa@xxxxxxxxx>

I suspect that if tboot was used with a different OS (Solaris?) it would hit
the same case and a similar hook would be needed.

Said 'hook' (which was a call to tboot_sleep) was converted to be a more neutral
'acpi_os_prepare_sleep' which tboot can use (and incidently Xen too).

I think what Bob is saying that if said hook is neccessary (and I believe 
it is - and Intel TXT maintainer thinks so too since he added it in the first 
place),
then the right way of adding it is via the ACPICA tree.

Should the discussion for this be moved there ? (https://acpica.org/community)
and an generic 'os_prepare_sleep' patch added in 
git://github.com/acpica/acpica.git?


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel