From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Len Brown <lenb@kernel.org>
Cc: "Cihula, Joseph" <joseph.cihula@intel.com>,
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 16:20:19 -0700 [thread overview]
Message-ID: <49CD5F33.7050100@goop.org> (raw)
In-Reply-To: <alpine.LFD.2.00.0903271744340.26419@localhost.localdomain>
Len Brown wrote:
>> 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...
>
Do you have an issue with the mechanism (using weak function, etc), or
just the placement of the prototypes in that header? Would there be a
better header to put them in? Or would you prefer some other mechanism?
It certainly seems like Xen and tboot should be able to share the same
hook, given that they're doing similar things for similar reasons.
(I don't really understand the structure of all the acpi stuff; I'm just
wading in and making a mess of things until I can close the lid of
laptop successfully.)
J
next prev parent reply other threads:[~2009-03-27 23:20 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
2009-03-27 23:20 ` Jeremy Fitzhardinge [this message]
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=49CD5F33.7050100@goop.org \
--to=jeremy@goop.org \
--cc=bjorn.helgaas@hp.com \
--cc=joseph.cihula@intel.com \
--cc=kevin.tian@intel.com \
--cc=len.brown@intel.com \
--cc=lenb@kernel.org \
--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