linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Andy Lutomirski <luto@myrealbox.com>,
	LKML <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	public-kernel-testers-u79uwXL29TY76Z2rM5mHXA@lo.gmane.org,
	Ingo Molnar <mingo@elte.hu>,
	pm list <linux-pm@lists.linux-foundation.org>
Subject: Re: [RFT] x86 acpi: normalize segment descriptor register on resume
Date: Sun, 13 Jul 2008 13:38:27 -0700	[thread overview]
Message-ID: <487A67C3.50000@zytor.com> (raw)
In-Reply-To: <487A617B.80707@firstfloor.org>

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

Andi Kleen wrote:
> 
> We're in real mode for now nd should not care about the hidden state.
> 

Sorry, Andi, that's not how real mode works.

That may be how real mode is *documented*, but that's not how it works.

The segment descriptor registers (what Intel calls "segment cache") is 
always active.  The only thing that changes based on CR0.PE is how it is 
*loaded* and the interpretation of the CS flags.

The segment descriptor registers contain of the following sub-registers: 
selector (the "visible" part), base, limit and flags.  In protected mode 
or long mode, they are loaded from descriptors (or fs.base or gs.base 
can be manipulated directly in long mode.)  In real mode, the only thing 
changed by a segment register load is the selector and the base, where 
the base <- selector << 4.  In particular, *the limit and the flags are 
not changed*.

As far as the handling of the CS flags: a code segment cannot be 
writable in protected mode, whereas it is "just another segment" in real 
mode, so there is some kind of quirk that kicks in for this when CR0.PE 
<- 0.  I'm not sure if this is accomplished by actually changing the 
cs.flags register or just changing the interpretation; it might be 
something that is CPU-specific.  In particular, the Transmeta CPUs had 
an explicit "CS is writable if you're in real mode" override, so even if 
you had loaded CS with an execute-only segment it'd be writable (but not 
readable!) on return to real mode.  I'm not at all sure if that is how 
other CPUs behave.

The most likely explanation for this is that the VESA BIOS expects to be 
entered in Big Real Mode (*.limit = 0xffffffff) instead of ordinary Real 
Mode.  Here is a completely untested patch which changes the segment 
descriptors to Big Real Mode instead.  It would be worth testing out.

	-hpa

[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 1282 bytes --]

diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c
index 36af01f..97648aa 100644
--- a/arch/x86/kernel/acpi/sleep.c
+++ b/arch/x86/kernel/acpi/sleep.c
@@ -23,6 +23,15 @@ static unsigned long acpi_realmode;
 static char temp_stack[10240];
 #endif
 
+/* XXX: this macro should move to asm-x86/segment.h and be shared with the
+   boot code... */
+#define GDT_ENTRY(flags, base, limit)		\
+	(((u64)(base & 0xff000000) << 32) |	\
+	 ((u64)flags << 40) |			\
+	 ((u64)(limit & 0x00ff0000) << 32) |	\
+	 ((u64)(base & 0x00ffffff) << 16) |	\
+	 ((u64)(limit & 0x0000ffff)))
+
 /**
  * acpi_save_state_mem - save kernel state
  *
@@ -58,11 +67,11 @@ int acpi_save_state_mem(void)
 			((char *)&header->wakeup_gdt - (char *)acpi_realmode))
 				<< 16);
 	/* GDT[1]: real-mode-like code segment */
-	header->wakeup_gdt[1] = (0x009bULL << 40) +
-		((u64)acpi_wakeup_address << 16) + 0xffff;
+	header->wakeup_gdt[1] =
+		GDT_ENTRY(0x809b, acpi_wakeup_address << 16, 0xfffff);
 	/* GDT[2]: real-mode-like data segment */
-	header->wakeup_gdt[2] = (0x0093ULL << 40) +
-		((u64)acpi_wakeup_address << 16) + 0xffff;
+	header->wakeup_gdt[2] =
+		GDT_ENTRY(0x8093, acpi_wakeup_address << 16, 0xfffff);
 
 #ifndef CONFIG_64BIT
 	store_gdt((struct desc_ptr *)&header->pmode_gdt);

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]



  parent reply	other threads:[~2008-07-13 20:38 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-30 23:48 [RFT] x86 acpi: normalize segment descriptor register on resume Rafael J. Wysocki
     [not found] ` <200807010148.02135.rjw-KKrjLPT3xs0@public.gmane.org>
2008-07-01  0:05   ` H. Peter Anvin
2008-07-01  6:31   ` Ingo Molnar
     [not found]     ` <20080701063133.GC16642-X9Un+BFzKDI@public.gmane.org>
2008-07-01  6:54       ` H. Peter Anvin
2008-07-01  9:19         ` Pavel Machek
2008-07-01 20:39         ` Rafael J. Wysocki
2008-07-01 20:42           ` Andi Kleen
2008-07-01 20:50             ` Rafael J. Wysocki
2008-07-01 20:52               ` Andi Kleen
     [not found]             ` <486A96C1.2020106-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>
2008-07-12  6:29               ` Andy Lutomirski
2008-07-12 12:08                 ` Andi Kleen
     [not found]                   ` <48789EC3.2070701-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>
2008-07-12 15:08                     ` Andy Lutomirski
     [not found]                 ` <48784F51.1010407-YSGFQ8SKJZVDPfheJLI6IQ@public.gmane.org>
2008-07-12 18:51                   ` Rafael J. Wysocki
2008-07-12 20:31                     ` Andy Lutomirski
2008-07-12 20:47                       ` Rafael J. Wysocki
2008-07-12 20:39                     ` Andy Lutomirski
2008-07-12 20:53                       ` Rafael J. Wysocki
2008-07-12 23:11                         ` Andy Lutomirski
2008-07-12 23:33                           ` Rafael J. Wysocki
2008-07-13  8:56                             ` Pavel Machek
2008-07-13 18:16                               ` H. Peter Anvin
2008-07-14  6:36                                 ` Pavel Machek
2008-07-13  9:15                             ` Ingo Molnar
2008-07-13 12:02                               ` Matthew Garrett
2008-07-13 15:50                                 ` Andy Lutomirski
2008-07-13 18:43                                   ` Andi Kleen
2008-07-13 19:15                                     ` Rafael J. Wysocki
2008-07-13 20:11                                       ` Andi Kleen
2008-07-13 20:29                                         ` Rafael J. Wysocki
2008-07-14  2:35                                           ` H. Peter Anvin
2008-07-14 20:10                                             ` Rafael J. Wysocki
2008-07-13 20:38                                         ` H. Peter Anvin [this message]
2008-07-14  1:31                                           ` Matthew Garrett
2008-07-14  4:18                                           ` H. Peter Anvin
2008-07-14  7:39                                             ` Pavel Machek
2008-07-14 20:09                                             ` Rafael J. Wysocki
2008-07-16 14:13                                             ` Andrew Lutomirski
2008-07-16 14:23                                               ` Ingo Molnar
2008-07-13 20:16                                     ` H. Peter Anvin
2008-07-13 20:21                                       ` Andi Kleen
2008-07-13 20:32                                         ` Rafael J. Wysocki
2008-07-14  1:22                                         ` Henrique de Moraes Holschuh
2008-07-14  6:14                                           ` Pavel Machek
2008-07-14 11:22                                             ` Henrique de Moraes Holschuh
2008-07-13 18:02                                 ` Rafael J. Wysocki
2008-07-01  7:02       ` H. Peter Anvin
2008-07-01 13:01         ` Andi Kleen
2008-07-01 15:55           ` H. Peter Anvin
     [not found]             ` <486A5378.7020601-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2008-07-01 16:21               ` Andi Kleen
2008-07-01 17:28                 ` H. Peter Anvin
2008-07-01  7:20 ` Ingo Molnar
     [not found]   ` <20080701072024.GB26601-X9Un+BFzKDI@public.gmane.org>
2008-07-01  7:28     ` Andrew Morton
2008-07-01  7:45       ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2008-07-12 23:07 H. Peter Anvin

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=487A67C3.50000@zytor.com \
    --to=hpa@zytor.com \
    --cc=andi@firstfloor.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=luto@myrealbox.com \
    --cc=mingo@elte.hu \
    --cc=public-kernel-testers-u79uwXL29TY76Z2rM5mHXA@lo.gmane.org \
    /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;
as well as URLs for NNTP newsgroup(s).