public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <lenb@kernel.org>
To: "Cihula, Joseph" <joseph.cihula@intel.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Bjorn Helgaas <bjorn.helgaas@hp.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	"Brown, Len" <len.brown@intel.com>,
	Xen-devel <xen-devel@lists.xensource.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"Wang, Shane" <shane.wang@intel.com>
Subject: RE: [Xen-devel] Re: Paravirtualizing bits of acpi access
Date: Fri, 27 Mar 2009 17:57:08 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.00.0903271744340.26419@localhost.localdomain> (raw)
In-Reply-To: <4F65016F6CB04E49BFFA15D4F7B798D9944E2524@orsmsx506.amr.corp.intel.com>


> > The two changes this patch makes are, unfortunately, unavoidable:
> >
> >    1. Turn the final "enter sleep" into a hypercall, so that Xen can do
> >       all the low-level context save/restore.  The normal baremetal case
> >       is still localized in acpica/hwsleep.c, but it (may) make an
> >       excursion into arch code to see if it should do something else, and
> >    2. Directly enter the sleep state, rather than save cpu context
> >       (which Xen does)
> >
> > Though, come to think of it, perhaps there's no harm in letting the
> > kernel do its own state-saving.  I'll check.

Certainly the less different than bare metal you can be, the better.

The last thing we need is to complicate something that in Linux
has only been sort of working for 


> diff -r 855cb34ca992 drivers/acpi/acpica/hwsleep.c
> --- a/drivers/acpi/acpica/hwsleep.c     Tue Mar 17 19:53:17 2009 -0400
> +++ b/drivers/acpi/acpica/hwsleep.c     Tue Mar 24 09:37:22 2009 -0700
> @@ -45,6 +45,7 @@
>  #include <acpi/acpi.h>
>  #include "accommon.h"
>  #include "actables.h"
> +#include <asm/tboot.h>
> 
>  #define _COMPONENT          ACPI_HARDWARE
>  ACPI_MODULE_NAME("hwsleep")
> @@ -332,6 +333,39 @@ acpi_status asmlinkage acpi_enter_sleep_
> 
>         PM1Acontrol |= sleep_enable_reg_info->access_bit_mask;
>         PM1Bcontrol |= sleep_enable_reg_info->access_bit_mask;
> +
> +#ifdef CONFIG_TXT
> +#define TB_COPY_GAS(tbg, g)                 \
> +       tbg.space_id = g.space_id;          \
> +       tbg.bit_width = g.bit_width;        \
> +       tbg.bit_offset = g.bit_offset;      \
> +       tbg.access_width = g.access_width;  \
> +       tbg.address = g.address;
> +
> +       if (tboot_in_measured_env()) {
> +               TB_COPY_GAS(tboot_shared->acpi_sinfo.pm1a_cnt_blk,
> +                           acpi_gbl_FADT.xpm1a_control_block);
> +               TB_COPY_GAS(tboot_shared->acpi_sinfo.pm1b_cnt_blk,
> +                           acpi_gbl_FADT.xpm1b_control_block);

Who'd a thunk that suddently everybody would want to scribble
on acpi_enter_sleep_state()?

Note that acpica/hwsleep.c is a file from ACPICA that we share
with BSD etc.  Yes, we manage local changes in Linux, but we
try to reduce them to zero over time, else we create a big
maintenace headache.

perhaps tboot_in_measured_env() could compile in as 0
for !CONFIG_TXT and you can get rid of the #ifdefs?

Jeremy, I'm not excited about a proposed change to acpixf.h --
this is the API to ACPICA...

thanks,
-Len Brown, Intel Open Source Technology Center

  reply	other threads:[~2009-03-27 21:57 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-21  6:09 Paravirtualizing bits of acpi access Jeremy Fitzhardinge
2009-03-21 17:10 ` Rafael J. Wysocki
2009-03-22  4:26   ` Jeremy Fitzhardinge
2009-03-22 11:28     ` Rafael J. Wysocki
2009-03-22 13:14       ` Ingo Molnar
2009-03-22 13:17         ` Rafael J. Wysocki
2009-03-22 17:07       ` Jeremy Fitzhardinge
2009-03-22 18:00         ` Rafael J. Wysocki
2009-03-23  3:29         ` Tian, Kevin
2009-03-23 18:20           ` [Xen-devel] " Rafael J. Wysocki
2009-03-23 19:07             ` Jeremy Fitzhardinge
2009-03-23 20:27               ` Rafael J. Wysocki
2009-03-23 20:42                 ` Jeremy Fitzhardinge
2009-03-24  5:14                 ` Jeremy Fitzhardinge
2009-03-24  5:33                   ` Tian, Kevin
2009-03-24  5:42                     ` Jeremy Fitzhardinge
2009-03-24  5:45                       ` Tian, Kevin
2009-03-24  7:05                         ` Jeremy Fitzhardinge
2009-03-24 16:45                           ` Bjorn Helgaas
2009-03-24 17:28                             ` Jeremy Fitzhardinge
2009-03-24 17:51                               ` [Xen-devel] " Cihula, Joseph
2009-03-27 21:57                                 ` Len Brown [this message]
2009-03-27 23:20                                   ` Jeremy Fitzhardinge
2009-03-28  1:01                                     ` Len Brown
2009-03-28  2:19                                       ` Tian, Kevin
2009-03-28  3:19                                       ` Jeremy Fitzhardinge
2009-03-28 13:56                                         ` Rafael J. Wysocki
2009-03-24 23:40                               ` Tian, Kevin
2009-03-24 23:51                               ` Tian, Kevin
2009-03-25  0:45                                 ` Jeremy Fitzhardinge
2009-03-23 19:52             ` [Xen-devel] " Matthew Garrett
2009-03-23 20:22               ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.0903271744340.26419@localhost.localdomain \
    --to=lenb@kernel.org \
    --cc=bjorn.helgaas@hp.com \
    --cc=jeremy@goop.org \
    --cc=joseph.cihula@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=shane.wang@intel.com \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox