From: Gleb N. <gl...@re...> - 2008-10-27 10:17:14
|
Hello, This patch series adds S3 (suspend to RAM) ACPI state to BIOS. Most changes concern themselves with preventing BIOS from using memory locations available to a guest OS. --- Gleb Natapov (6): Don't power down vga card on entering S3 state. Don't use unreserved memory in BIOS. Execute rombios32 code from rom address 0xe0000. Disable init of SMM. Add S3 state to DSDT. Handle resume event in the BIOS. Move PIC initialization out of line to save space in post code area. bios/Makefile.in | 1 bios/acpi-dsdt.dsl | 45 +++++- bios/acpi-dsdt.hex | 376 +++++++++++++++++++++++++------------------------ bios/rombios.c | 105 ++++++++------ bios/rombios.h | 2 bios/rombios32.c | 75 +++++++++- bios/rombios32.ld | 8 - bios/rombios32start.S | 9 + 8 files changed, 377 insertions(+), 244 deletions(-) mode change 100644 => 100755 bios/acpi-dsdt.dsl mode change 100644 => 100755 bios/rombios32.c -- Gleb. |
From: Gleb N. <gl...@re...> - 2008-10-27 10:17:04
|
Signed-off-by: Gleb Natapov <gl...@re...> --- bios/Makefile.in | 1 + bios/rombios.c | 17 +---------------- bios/rombios32.ld | 8 +++----- bios/rombios32start.S | 9 ++++++++- 4 files changed, 13 insertions(+), 22 deletions(-) diff --git a/bios/Makefile.in b/bios/Makefile.in index b055910..af674b4 100644 --- a/bios/Makefile.in +++ b/bios/Makefile.in @@ -106,6 +106,7 @@ rombios32.o: rombios32.c acpi-dsdt.hex ifeq ("1", "0") acpi-dsdt.hex: acpi-dsdt.dsl iasl -tc -p $@ $< + sed -i -e's/^unsigned/const unsigned/' $@ endif rombios32start.o: rombios32start.S diff --git a/bios/rombios.c b/bios/rombios.c index 46996fa..c4c1e35 100644 --- a/bios/rombios.c +++ b/bios/rombios.c @@ -10020,13 +10020,6 @@ rombios32_05: mov gs, ax cld - ;; copy rombios32 code to ram (ram offset = 1MB) - mov esi, #0xfffe0000 - mov edi, #0x00040000 - mov ecx, #0x10000 / 4 - rep - movsd - ;; init the stack pointer mov esp, #0x00080000 @@ -10035,17 +10028,9 @@ rombios32_05: push #0x04b2 ;; call rombios32 code - mov eax, #0x00040000 + mov eax, #0x000e0000 call eax - ;; reset the memory (some boot loaders such as syslinux suppose - ;; that the memory is set to zero) - mov edi, #0x00040000 - mov ecx, #0x40000 / 4 - xor eax, eax - rep - stosd - ;; return to 16 bit protected mode first db 0xea dd rombios32_10 diff --git a/bios/rombios32.ld b/bios/rombios32.ld index c7f6066..113a2c0 100644 --- a/bios/rombios32.ld +++ b/bios/rombios32.ld @@ -3,14 +3,12 @@ OUTPUT_ARCH(i386) ENTRY(_start); SECTIONS { - . = 0x00040000; + . = 0x000e0000; .text : { *(.text) } .rodata : { *(.rodata) } - . = ALIGN(4096); - .data : { *(.data) } - __bss_start = . ; - .bss : { *(.bss) *(COMMON) } _end = . ; + .data 0x700 : AT (_end) { __data_start = .; *(.data); __data_end = .;} + .bss : { __bss_start = .; *(.bss) *(COMMON); __bss_end = .;} /DISCARD/ : { *(.stab) *(.stabstr) *(.comment) diff --git a/bios/rombios32start.S b/bios/rombios32start.S index 601e2b0..1900261 100644 --- a/bios/rombios32start.S +++ b/bios/rombios32start.S @@ -32,10 +32,17 @@ _start: /* clear bss section */ xor %eax, %eax mov $__bss_start, %edi - mov $_end, %ecx + mov $__bss_end, %ecx sub %edi, %ecx rep stosb + /* copy data section */ + mov $_end, %esi + mov $__data_start, %edi + mov $__data_end, %ecx + sub %edi, %ecx + rep movsb + jmp rombios32_init .code16 |
From: Gleb N. <gl...@re...> - 2008-10-27 10:18:56
|
There are only a couple of bytes left in post area. Signed-off-by: Gleb Natapov <gl...@re...> --- bios/rombios.c | 48 ++++++++++++++++++++++++++---------------------- 1 files changed, 26 insertions(+), 22 deletions(-) diff --git a/bios/rombios.c b/bios/rombios.c index 3366ad9..88eac04 100644 --- a/bios/rombios.c +++ b/bios/rombios.c @@ -10256,6 +10256,31 @@ rom_scan_increment: mov ds, ax ret +post_init_pic: + mov al, #0x11 ; send initialisation commands + out 0x20, al + out 0xa0, al + mov al, #0x08 + out 0x21, al + mov al, #0x70 + out 0xa1, al + mov al, #0x04 + out 0x21, al + mov al, #0x02 + out 0xa1, al + mov al, #0x01 + out 0x21, al + out 0xa1, al + mov al, #0xb8 + out 0x21, AL ;master pic: unmask IRQ 0, 1, 2, 6 +#if BX_USE_PS2_MOUSE + mov al, #0x8f +#else + mov al, #0x9f +#endif + out 0xa1, AL ;slave pic: unmask IRQ 12, 13, 14 + ret + ;; the following area can be used to write dynamically generated tables .align 16 bios_table_area_start: @@ -10516,28 +10541,7 @@ post_default_ints: SET_INT_VECTOR(0x10, #0xF000, #int10_handler) ;; PIC - mov al, #0x11 ; send initialisation commands - out 0x20, al - out 0xa0, al - mov al, #0x08 - out 0x21, al - mov al, #0x70 - out 0xa1, al - mov al, #0x04 - out 0x21, al - mov al, #0x02 - out 0xa1, al - mov al, #0x01 - out 0x21, al - out 0xa1, al - mov al, #0xb8 - out 0x21, AL ;master pic: unmask IRQ 0, 1, 2, 6 -#if BX_USE_PS2_MOUSE - mov al, #0x8f -#else - mov al, #0x9f -#endif - out 0xa1, AL ;slave pic: unmask IRQ 12, 13, 14 + call post_init_pic mov cx, #0xc000 ;; init vga bios mov ax, #0xc780 |
From: Gleb N. <gl...@re...> - 2008-10-27 10:19:02
|
Signed-off-by: Gleb Natapov <gl...@re...> --- bios/acpi-dsdt.dsl | 30 ++++++++++++++++++---- bios/acpi-dsdt.hex | 17 +++++++----- bios/rombios.c | 34 +++++++++++++++++++++++++ bios/rombios32.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++--- 4 files changed, 135 insertions(+), 17 deletions(-) diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl index 19ac2f9..f201396 100644 --- a/bios/acpi-dsdt.dsl +++ b/bios/acpi-dsdt.dsl @@ -531,11 +531,29 @@ DefinitionBlock ( } } - /* S5 = power off state */ - Name (_S5, Package (4) { - 0x00, // PM1a_CNT.SLP_TYP - 0x00, // PM2a_CNT.SLP_TYP - 0x00, // reserved - 0x00, // reserved + /* + * S3 (suspend-to-ram), S4 (suspend-to-disc) and S5 (power-off) type codes: + * must match piix4 emulation. + */ + Name (\_S3, Package (0x04) + { + 0x01, /* PM1a_CNT.SLP_TYP */ + 0x01, /* PM1b_CNT.SLP_TYP */ + Zero, /* reserved */ + Zero /* reserved */ + }) + Name (\_S4, Package (0x04) + { + Zero, /* PM1a_CNT.SLP_TYP */ + Zero, /* PM1b_CNT.SLP_TYP */ + Zero, /* reserved */ + Zero /* reserved */ + }) + Name (\_S5, Package (0x04) + { + Zero, /* PM1a_CNT.SLP_TYP */ + Zero, /* PM1b_CNT.SLP_TYP */ + Zero, /* reserved */ + Zero /* reserved */ }) } diff --git a/bios/acpi-dsdt.hex b/bios/acpi-dsdt.hex index 6bc6268..6088b18 100644 --- a/bios/acpi-dsdt.hex +++ b/bios/acpi-dsdt.hex @@ -1,22 +1,22 @@ /* * * Intel ACPI Component Architecture - * ASL Optimizing Compiler version 20060912 [Nov 25 2006] + * ASL Optimizing Compiler version 20061109 [May 15 2007] * Copyright (C) 2000 - 2006 Intel Corporation * Supports ACPI Specification Revision 3.0a * - * Compilation of "acpi-dsdt.dsl" - Sun Sep 14 10:27:40 2008 + * Compilation of "acpi-dsdt.dsl" - Mon Oct 27 10:37:05 2008 * * C source code output * */ -unsigned char AmlCode[] = +const unsigned char AmlCode[] = { - 0x44,0x53,0x44,0x54,0xC9,0x07,0x00,0x00, /* 00000000 "DSDT...." */ - 0x01,0x0E,0x42,0x58,0x50,0x43,0x00,0x00, /* 00000008 "..BXPC.." */ + 0x44,0x53,0x44,0x54,0xE1,0x07,0x00,0x00, /* 00000000 "DSDT...." */ + 0x01,0x24,0x42,0x58,0x50,0x43,0x00,0x00, /* 00000008 ".$BXPC.." */ 0x42,0x58,0x44,0x53,0x44,0x54,0x00,0x00, /* 00000010 "BXDSDT.." */ 0x01,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 "....INTL" */ - 0x12,0x09,0x06,0x20,0x10,0x1C,0x5C,0x00, /* 00000020 "... ..\." */ + 0x09,0x11,0x06,0x20,0x10,0x1C,0x5C,0x00, /* 00000020 "... ..\." */ 0x5B,0x80,0x44,0x42,0x47,0x5F,0x01,0x0B, /* 00000028 "[.DBG_.." */ 0x44,0xB0,0x0A,0x04,0x5B,0x81,0x0B,0x44, /* 00000030 "D...[..D" */ 0x42,0x47,0x5F,0x03,0x44,0x42,0x47,0x4C, /* 00000038 "BG_.DBGL" */ @@ -260,6 +260,9 @@ unsigned char AmlCode[] = 0x8B,0x68,0x01,0x54,0x4D,0x50,0x5F,0x82, /* 000007A8 ".h.TMP_." */ 0x54,0x4D,0x50,0x5F,0x60,0x76,0x60,0x70, /* 000007B0 "TMP_`v`p" */ 0x60,0x50,0x52,0x51,0x33,0x08,0x5F,0x53, /* 000007B8 "`PRQ3._S" */ - 0x35,0x5F,0x12,0x06,0x04,0x00,0x00,0x00, /* 000007C0 "5_......" */ + 0x33,0x5F,0x12,0x06,0x04,0x01,0x01,0x00, /* 000007C0 "3_......" */ + 0x00,0x08,0x5F,0x53,0x34,0x5F,0x12,0x06, /* 000007C8 ".._S4_.." */ + 0x04,0x00,0x00,0x00,0x00,0x08,0x5F,0x53, /* 000007D0 "......_S" */ + 0x35,0x5F,0x12,0x06,0x04,0x00,0x00,0x00, /* 000007D8 "5_......" */ 0x00, }; diff --git a/bios/rombios.c b/bios/rombios.c index 88eac04..46996fa 100644 --- a/bios/rombios.c +++ b/bios/rombios.c @@ -2198,6 +2198,31 @@ debugger_off() outb(0xfedc, 0x00); } +void +s3_resume() +{ + Bit32u s3_wakeup_vector; + Bit8u s3_resume_flag; + + s3_resume_flag = read_byte(0x40, 0xb0); + s3_wakeup_vector = read_dword(0x40, 0xb2); + + BX_INFO("S3 resume called %x 0x%lx\n", s3_resume_flag, s3_wakeup_vector); + if (s3_resume_flag != 0xFE || !s3_wakeup_vector) + return; + + write_byte(0x40, 0xb0, 0); + + /* setup wakeup vector */ + write_word(0x40, 0xb6, (s3_wakeup_vector & 0xF)); /* IP */ + write_word(0x40, 0xb8, (s3_wakeup_vector >> 4)); /* CS */ + + BX_INFO("S3 resume jump to %x:%x\n", *(Bit16u*)0x04b8, *(Bit16u*)0x04b6); +ASM_START + jmpf [0x04b6] +ASM_END +} + #if BX_USE_ATADRV // --------------------------------------------------------------------------- @@ -10005,6 +10030,10 @@ rombios32_05: ;; init the stack pointer mov esp, #0x00080000 + ;; pass pointer to s3_resume_flag and s3_resume_vector to rombios32 + push #0x04b0 + push #0x04b2 + ;; call rombios32 code mov eax, #0x00040000 call eax @@ -10383,6 +10412,9 @@ normal_post: rep stosw + ;; Save shutdown status + mov 0x04b0, bl + call _log_bios_start ;; set all interrupts to default handler @@ -10593,6 +10625,8 @@ post_default_ints: mov ax, #0xe000 call rom_scan + call _s3_resume + #if BX_ELTORITO_BOOT call _interactive_bootkey #endif // BX_ELTORITO_BOOT diff --git a/bios/rombios32.c b/bios/rombios32.c index f0daf15..ff84f80 100644 --- a/bios/rombios32.c +++ b/bios/rombios32.c @@ -180,6 +180,20 @@ void *memmove(void *d1, const void *s1, size_t len) return d1; } +int memcmp(const void *s1, const void *s2, size_t len) +{ + const int8_t *p1 = s1; + const int8_t *p2 = s2; + + while (len--) { + int r = *p1++ - *p2++; + if(r) + return r; + } + + return 0; +} + size_t strlen(const char *s) { const char *s1; @@ -644,7 +658,7 @@ static void bios_shadow_init(PCIDevice *d) { int v; - if (find_bios_table_area() < 0) + if (bios_table_cur_addr == 0) return; /* remap the BIOS to shadow RAM an keep it read/write while we @@ -1461,7 +1475,7 @@ void acpi_bios_init(void) memset(facs, 0, sizeof(*facs)); memcpy(facs->signature, "FACS", 4); facs->length = cpu_to_le32(sizeof(*facs)); - + BX_INFO("Firmware waking vector %p\n", &facs->firmware_waking_vector); /* DSDT */ memcpy(dsdt, AmlCode, sizeof(AmlCode)); @@ -2011,9 +2025,40 @@ void smbios_init(void) BX_INFO("SMBIOS table addr=0x%08lx\n", (unsigned long)start); } -void rombios32_init(void) +static uint32_t find_resume_vector(void) { - BX_INFO("Starting rombios32\n"); + unsigned long addr; + + if (bios_table_cur_addr == 0) + return 0; + + for (addr = bios_table_cur_addr; addr < bios_table_end_addr; addr++) { + if (!memcmp((void*)addr, "RSD PTR ", 8)) { + struct rsdp_descriptor *rsdp = (void*)addr; + struct rsdt_descriptor_rev1 *rsdt = (void*)rsdp->rsdt_physical_address; + struct fadt_descriptor_rev1 *fadt = (void*)rsdt->table_offset_entry[0]; + struct facs_descriptor_rev1 *facs = (void*)fadt->firmware_ctrl; + return facs->firmware_waking_vector; + } + } + + return 0; +} + +static void find_440fx(PCIDevice *d) +{ + uint16_t vendor_id, device_id; + + vendor_id = pci_config_readw(d, PCI_VENDOR_ID); + device_id = pci_config_readw(d, PCI_DEVICE_ID); + + if (vendor_id == 0x8086 && device_id == 0x1237) + i440_pcidev = *d; +} + +void rombios32_init(uint32_t *s3_resume_vector, uint8_t *shutdown_flag) +{ + BX_INFO("Starting rombios32 %p %p %x\n", s3_resume_vector, shutdown_flag, *shutdown_flag); #ifdef BX_QEMU qemu_cfg_port = qemu_cfg_port_probe(); @@ -2025,6 +2070,24 @@ void rombios32_init(void) smp_probe(); + if (find_bios_table_area() < 0) + return; + + if (*shutdown_flag == 0xfe) { + *s3_resume_vector = find_resume_vector(); + if (!*s3_resume_vector) { + BX_INFO("This is S3 resume but wakeup vector is NULL\n"); + } else { + BX_INFO("S3 resume vector %p\n", *s3_resume_vector); + /* redirect bios read access to RAM */ + pci_for_each_device(find_440fx); + bios_lock_shadow_ram(); /* bios is already copied */ + return; + } + } + + uuid_probe(); + pci_bios_init(); if (bios_table_cur_addr != 0) { |
From: Gleb N. <gl...@re...> - 2008-10-27 10:19:06
|
SMM initialization uses memory available for OS use. Signed-off-by: Gleb Natapov <gl...@re...> --- bios/rombios32.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) mode change 100644 => 100755 bios/rombios32.c diff --git a/bios/rombios32.c b/bios/rombios32.c old mode 100644 new mode 100755 index ff84f80..e887d71 --- a/bios/rombios32.c +++ b/bios/rombios32.c @@ -38,7 +38,7 @@ typedef unsigned long long uint64_t; //#define BX_USE_EBDA_TABLES /* define it if the (emulated) hardware supports SMM mode */ -#define BX_USE_SMM +//#define BX_USE_SMM #define cpuid(index, eax, ebx, ecx, edx) \ asm volatile ("cpuid" \ |
From: Stanislav S. <stl...@gm...> - 2008-10-27 11:34:05
|
Could you explain a bit more about these patches ? Bochs doesn't support S3 or any other power state, so if you enable it in BIOS the will try to them which will cause unpredictable behavior in CPU emulation. Are you sure Bochs will live well with this change ? Are you sure that disabling SMM is good idea ? I don't understand what do you mean by "SMM initialization uses memory available for OS use". SMM state map area is hidden memory below video card and sure it is not available for OS use. Stanislav -----Original Message----- From: Gleb Natapov [mailto:gl...@re...] Sent: Monday, October 27, 2008 12:13 PM To: boc...@li... Cc: qem...@no... Subject: [Bochs-developers] [PATCH 3/6] Disable init of SMM. SMM initialization uses memory available for OS use. Signed-off-by: Gleb Natapov <gl...@re...> --- bios/rombios32.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) mode change 100644 => 100755 bios/rombios32.c diff --git a/bios/rombios32.c b/bios/rombios32.c old mode 100644 new mode 100755 index ff84f80..e887d71 --- a/bios/rombios32.c +++ b/bios/rombios32.c @@ -38,7 +38,7 @@ typedef unsigned long long uint64_t; //#define BX_USE_EBDA_TABLES /* define it if the (emulated) hardware supports SMM mode */ -#define BX_USE_SMM +//#define BX_USE_SMM #define cpuid(index, eax, ebx, ecx, edx) \ asm volatile ("cpuid" \ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ bochs-developers mailing list boc...@li... https://lists.sourceforge.net/lists/listinfo/bochs-developers |
From: Gleb N. <gl...@re...> - 2008-10-27 12:39:43
|
On Mon, Oct 27, 2008 at 12:58:36PM +0200, Stanislav Shwartsman wrote: > Could you explain a bit more about these patches ? > Suspend to ram (or "stand by" in windows) is a machine state when only memory gets the power and all other devices including CPU are powered down. The memory content is preserved and OS can resume almost instantly. In order for BIOS to support S3 it shouldn't touch any memory that is not listed as reserved in e820 map, otherwise it may overwrite OS data and OS will crash after resume. Bochs BIOS touches memory in a couple of places (for instance rombios32 is copied into the low memory location before execution). Those patches eliminate all the places where BIOS uses main memory and handles resume path by jumping to resume routing provided by an OS instead of regular boot from a disk. > Bochs doesn't support S3 or any other power state, so if you enable it in Bochs support ACPI and that is almost everything that is needed. I have a patch for bochs to handle S3, but cpu reset doesn't work for me in current CVS (reboot from inside a guest doesn't work), so I can't test it. > BIOS the will try to them which will cause unpredictable behavior in CPU > emulation. S3 has nothing to do with CPU emulation. > Are you sure Bochs will live well with this change ? I've run bochs with new BIOS. > Are you sure that disabling SMM is good idea ? I don't understand what do If you ask me I think that SMM is a horrible idea in itself :). If emulated hardware will never issue SMI then SMM will never be used. > you mean by "SMM initialization uses memory available for OS use". The problem with SMM is that it assumes that SMI handler is located in fixed memory location (0x38000). The sad thing is that to reprogram CPU to use different location SMM should be entered at least once using its default memory location. > SMM state map area is hidden memory below video card and sure it is not > available for OS use. It is there only after it is reprogrammed to be there and this process have to touch 0x38000 physical address. BIOS can save memory content at this location, reprogram SMM entry point and copy old content back, but who is really using SMM in emulated HW? -- Gleb. |
From: Stanislav S. <stl...@gm...> - 2008-10-27 12:35:34
|
Hi Gleb, > you mean by "SMM initialization uses memory available for OS use". The problem with SMM is that it assumes that SMI handler is located in fixed memory location (0x38000). The sad thing is that to reprogram CPU to use different location SMM should be entered at least once using its default memory location. > SMM state map area is hidden memory below video card and sure it is not > available for OS use. It is there only after it is reprogrammed to be there and this process have to touch 0x38000 physical address. BIOS can save memory content at this location, reprogram SMM entry point and copy old content back, but who is really using SMM in emulated HW? The answer is pretty easy. Even WindowsXP sends SMI and enters SMM during its boot. The same for any modern Linux image you can download. The hardware supports entering to SMM and guest OS could send you into SMM so it must be supported. So instead of turning it off in BIOS, just keep this part of code which enters to SMM once in the very beginning, program SMM properly and exit. Stanislav -----Original Message----- From: Gleb Natapov [mailto:gl...@re...] Sent: Monday, October 27, 2008 2:01 PM To: Stanislav Shwartsman Cc: boc...@li... Subject: Re: [Bochs-developers] [PATCH 3/6] Disable init of SMM. On Mon, Oct 27, 2008 at 12:58:36PM +0200, Stanislav Shwartsman wrote: > Could you explain a bit more about these patches ? > Suspend to ram (or "stand by" in windows) is a machine state when only memory gets the power and all other devices including CPU are powered down. The memory content is preserved and OS can resume almost instantly. In order for BIOS to support S3 it shouldn't touch any memory that is not listed as reserved in e820 map, otherwise it may overwrite OS data and OS will crash after resume. Bochs BIOS touches memory in a couple of places (for instance rombios32 is copied into the low memory location before execution). Those patches eliminate all the places where BIOS uses main memory and handles resume path by jumping to resume routing provided by an OS instead of regular boot from a disk. > Bochs doesn't support S3 or any other power state, so if you enable it in Bochs support ACPI and that is almost everything that is needed. I have a patch for bochs to handle S3, but cpu reset doesn't work for me in current CVS (reboot from inside a guest doesn't work), so I can't test it. > BIOS the will try to them which will cause unpredictable behavior in CPU > emulation. S3 has nothing to do with CPU emulation. > Are you sure Bochs will live well with this change ? I've run bochs with new BIOS. > Are you sure that disabling SMM is good idea ? I don't understand what do If you ask me I think that SMM is a horrible idea in itself :). If emulated hardware will never issue SMI then SMM will never be used. > you mean by "SMM initialization uses memory available for OS use". The problem with SMM is that it assumes that SMI handler is located in fixed memory location (0x38000). The sad thing is that to reprogram CPU to use different location SMM should be entered at least once using its default memory location. > SMM state map area is hidden memory below video card and sure it is not > available for OS use. It is there only after it is reprogrammed to be there and this process have to touch 0x38000 physical address. BIOS can save memory content at this location, reprogram SMM entry point and copy old content back, but who is really using SMM in emulated HW? -- Gleb. |
From: Gleb N. <gl...@re...> - 2008-10-27 14:33:01
|
On Mon, Oct 27, 2008 at 02:34:30PM +0200, Stanislav Shwartsman wrote: > Hi Gleb, > > > you mean by "SMM initialization uses memory available for OS use". > The problem with SMM is that it assumes that SMI handler is located in > fixed memory location (0x38000). The sad thing is that to reprogram CPU > to use different location SMM should be entered at least once using > its default memory location. > > > SMM state map area is hidden memory below video card and sure it is not > > available for OS use. > It is there only after it is reprogrammed to be there and this process > have to touch 0x38000 physical address. BIOS can save memory content at > this location, reprogram SMM entry point and copy old content back, but > who is really using SMM in emulated HW? > > The answer is pretty easy. Even WindowsXP sends SMI and enters SMM during > its boot. > The same for any modern Linux image you can download. KVM doesn't support SMM and Windows and Linux works without any problems. SMM was used on legacy systems for power management. ACPI replaced that long time ago. All bochs BIOS SMM handler does is enables/disable ACPI. Actually I just booted Linux and Windows 2003 and there was no single SMI during boot. > The hardware supports entering to SMM and guest OS could send you into SMM > so it must be supported. > So instead of turning it off in BIOS, just keep this part of code which > enters to SMM once in the very beginning, program SMM properly and exit. > In S3 state CPU is powered down so SMBASE will be reset to default value on resume. The result will be different value of SMBASE after resume. -- Gleb. |
From: Sebastian H. <he...@gm...> - 2008-10-30 21:42:23
|
Gleb Natapov wrote: > In S3 state CPU is powered down so SMBASE will be reset to default value > on resume. The result will be different value of SMBASE after resume. The ACPI spec says "If this is an S2 or S3 wake, then the BIOS restores minimum context of the system before jumping to the waking vector. This includes: * CPU configuration. BIOS restores the pre-sleep configuration or initial boot configuration of each CPU (MSR, MTRR, BIOS update, SMBase, and so on)". Depending on what's "initial boot configuration" the BIOS might have to set up the SMBASE or might not have to care about it. - Sebastian |
From: Gleb N. <gl...@re...> - 2008-11-02 09:37:37
|
On Thu, Oct 30, 2008 at 10:33:09PM +0100, Sebastian Herbszt wrote: > Gleb Natapov wrote: >> In S3 state CPU is powered down so SMBASE will be reset to default value >> on resume. The result will be different value of SMBASE after resume. > > The ACPI spec says > "If this is an S2 or S3 wake, then the BIOS restores minimum context of the system > before jumping to the waking vector. This includes: > * CPU configuration. BIOS restores the pre-sleep configuration or initial boot > configuration of each CPU (MSR, MTRR, BIOS update, SMBase, and so on)". > > Depending on what's "initial boot configuration" the BIOS might have to set > up the SMBASE or might not have to care about it. > Exactly. So we have to always set up SMBASE on never set up SMBASE, doing it only on a regular boot is wrong. -- Gleb. |
From: Kevin O'C. <ke...@ko...> - 2008-10-28 00:03:31
|
Hi Gleb, On Mon, Oct 27, 2008 at 02:01:12PM +0200, Gleb Natapov wrote: > On Mon, Oct 27, 2008 at 12:58:36PM +0200, Stanislav Shwartsman wrote: > > Could you explain a bit more about these patches ? > > > Suspend to ram (or "stand by" in windows) is a machine state when only > memory gets the power and all other devices including CPU are powered > down. The memory content is preserved and OS can resume almost > instantly. In order for BIOS to support S3 it shouldn't touch any memory > that is not listed as reserved in e820 map, otherwise it may overwrite > OS data and OS will crash after resume. I think we're better off detecting that the boot is an S3 resume and then avoid touching any memory in that case. I think trying to change the bios so that all boots don't touch any memory is going to be fragile. Also, the code looks like it is trying to run the option roms after an S3 resume. This doesn't seem right, as I think the option roms themselves could clobber memory. -Kevin |
From: Gleb N. <gl...@re...> - 2008-10-28 07:14:39
|
On Mon, Oct 27, 2008 at 07:44:48PM -0400, Kevin O'Connor wrote: > Hi Gleb, > > On Mon, Oct 27, 2008 at 02:01:12PM +0200, Gleb Natapov wrote: > > On Mon, Oct 27, 2008 at 12:58:36PM +0200, Stanislav Shwartsman wrote: > > > Could you explain a bit more about these patches ? > > > > > Suspend to ram (or "stand by" in windows) is a machine state when only > > memory gets the power and all other devices including CPU are powered > > down. The memory content is preserved and OS can resume almost > > instantly. In order for BIOS to support S3 it shouldn't touch any memory > > that is not listed as reserved in e820 map, otherwise it may overwrite > > OS data and OS will crash after resume. > > I think we're better off detecting that the boot is an S3 resume and > then avoid touching any memory in that case. I think trying to change > the bios so that all boots don't touch any memory is going to be > fragile. > Why make spacial cases? From all the changes I did what, in your opinion, should be done different on a regular boot vs S3 resume? Actually, on the second thought, I did exactly what you said. The BIOS shadowing (the copying part of it) is done only on the regular boot and not during S3 resume. We can argue about SMM. If it is needed at all, or should it be initialized only on a first boot or on each boot. All options are easy to implement. I chose the first once since AFAIK SMM is a legacy thing, but if this part of the patch series prevent the whole series to be merged I am open to implement other suggestions. > Also, the code looks like it is trying to run the option roms after an > S3 resume. This doesn't seem right, as I think the option roms > themselves could clobber memory. > Then this is the problem of an optional rom and it should be fixed. I don't think we have an option to not run optional rom on resume since HW has to be re-initialized, do I miss something? Anyway it is easy to skip optional rom on resume if this is necessary. -- Gleb. |
From: Sebastian H. <he...@gm...> - 2008-10-30 21:12:14
|
Gleb Natapov wrote: > On Mon, Oct 27, 2008 at 07:44:48PM -0400, Kevin O'Connor wrote: >> Also, the code looks like it is trying to run the option roms after an >> S3 resume. This doesn't seem right, as I think the option roms >> themselves could clobber memory. >> > Then this is the problem of an optional rom and it should be fixed. I > don't think we have an option to not run optional rom on resume since HW > has to be re-initialized, do I miss something? Anyway it is easy to skip > optional rom on resume if this is necessary. An option rom could use the POST Memory Manager (PMM) to allocate a conventional memory block (0 to 1MB). According to the ACPI spec the wake function is located in memory below 1MB. The BIOS could hand out memory where the wake function is located and the option rom would overwrite it if it is called during S3 resume. - Sebastian |
From: Gleb N. <gl...@re...> - 2008-11-02 09:40:49
|
On Thu, Oct 30, 2008 at 10:10:07PM +0100, Sebastian Herbszt wrote: > Gleb Natapov wrote: >> On Mon, Oct 27, 2008 at 07:44:48PM -0400, Kevin O'Connor wrote: >>> Also, the code looks like it is trying to run the option roms after an >>> S3 resume. This doesn't seem right, as I think the option roms >>> themselves could clobber memory. >>> >> Then this is the problem of an optional rom and it should be fixed. I >> don't think we have an option to not run optional rom on resume since HW >> has to be re-initialized, do I miss something? Anyway it is easy to skip >> optional rom on resume if this is necessary. > > An option rom could use the POST Memory Manager (PMM) to allocate > a conventional memory block (0 to 1MB). According to the ACPI spec the > wake function is located in memory below 1MB. The BIOS could hand out > memory where the wake function is located and the option rom would > overwrite it if it is called during S3 resume. > BIOS knows that it does S3 resume. Why should it allocate memory from a range that belongs to an OS? -- Gleb. |
From: Sebastian H. <he...@gm...> - 2008-11-11 23:01:49
|
Stanislav Shwartsman wrote: > Not from debug print :( > It prints that CPU is out of CS limits so probably you running in bogus > memory or just the code segment became too big. As far as i understand bx_pc_system_c::Reset() it should put the CPU in the same state as power on by calling BX_CPU_C::reset(). So if i call it somewhere in Bochs the CPU should start executing the BIOS again. When i start Bochs i get the following CPU state: 00000000000i[CPU0 ] CPU is in real mode (active) 00000000000i[CPU0 ] CS.d_b = 16 bit 00000000000i[CPU0 ] SS.d_b = 16 bit 00000000000i[CPU0 ] | EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000683 00000000000i[CPU0 ] | ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 00000000000i[CPU0 ] | IOPL=0 id vip vif ac vm rf nt of df if tf sf zf af pf cf 00000000000i[CPU0 ] | SEG selector base limit G D 00000000000i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D 00000000000i[CPU0 ] | CS:f000( 1e00| 0| 0) ffff0000 0000ffff 0 0 00000000000i[CPU0 ] | DS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00000000000i[CPU0 ] | SS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00000000000i[CPU0 ] | ES:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00000000000i[CPU0 ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00000000000i[CPU0 ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00000000000i[CPU0 ] | EIP=0000fff0 (0000fff0) 00000000000i[CPU0 ] | CR0=0x60000010 CR2=0x00000000 00000000000i[CPU0 ] | CR3=0x00000000 CR4=0x00000000 If i press the reset button while the linux kernel is starting and let it end simulation on CPU BX_ERROR() i get 00446059986e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff] or 00354300004e[CPU0 ] branch_near32: offset outside of CS limits or other errors and the CPU state looks like 00446060000i[CPU0 ] CPU is in real mode (active) 00446060000i[CPU0 ] CS.d_b = 16 bit 00446060000i[CPU0 ] SS.d_b = 16 bit 00446060000i[CPU0 ] | EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000683 00446060000i[CPU0 ] | ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 00446060000i[CPU0 ] | IOPL=0 id vip vif ac vm rf nt of df if tf sf ZF af PF cf 00446060000i[CPU0 ] | SEG selector base limit G D 00446060000i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D 00446060000i[CPU0 ] | CS:f000( 1e00| 0| 0) 000f0000 0000ffff 0 0 00446060000i[CPU0 ] | DS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00446060000i[CPU0 ] | SS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00446060000i[CPU0 ] | ES:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00446060000i[CPU0 ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00446060000i[CPU0 ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00446060000i[CPU0 ] | EIP=0000ffff (0000ffff) 00446060000i[CPU0 ] | CR0=0x60000010 CR2=0x00000000 00446060000i[CPU0 ] | CR3=0x00000000 CR4=0x00000000 00446060000i[CPU0 ] (instruction unavailable) page split instruction Gleb, does the CPU state look similar when you experience CPU reset failures? - Sebastian |
From: Gleb N. <gl...@re...> - 2008-11-12 10:25:36
|
On Wed, Nov 12, 2008 at 12:00:23AM +0100, Sebastian Herbszt wrote: > Gleb, does the CPU state look similar when you experience CPU reset failures? > When I press reset I get: 04557920002e[CPU0 ] prefetch: EIP [000109c6] > CS.limit [0000ffff] 04557920033i[CPU0 ] WARNING: HLT instruction with IF=0! The I press power off and get this: 04807120000p[XGUI ] >>PANIC<< POWER button turned off. 04807120000i[CPU0 ] CPU is in real mode (halted) 04807120000i[CPU0 ] CS.d_b = 16 bit 04807120000i[CPU0 ] SS.d_b = 16 bit 04807120000i[CPU0 ] EFER = 0x00000000 04807120000i[CPU0 ] | RAX=000000000000f001 RBX=0000000000000000 04807120000i[CPU0 ] | RCX=0000000000000000 RDX=0000000000000f20 04807120000i[CPU0 ] | RSP=0000000000000000 RBP=0000000000000000 04807120000i[CPU0 ] | RSI=0000000000000000 RDI=0000000000000000 04807120000i[CPU0 ] | R8=0000000000000000 R9=0000000000000000 04807120000i[CPU0 ] | R10=0000000000000000 R11=0000000000000000 04807120000i[CPU0 ] | R12=0000000000000000 R13=0000000000000000 04807120000i[CPU0 ] | R14=0000000000000000 R15=0000000000000000 04807120000i[CPU0 ] | IOPL=0 id vip vif ac vm rf nt of df if tf sf zf af pf cf 04807120000i[CPU0 ] | SEG selector base limit G D 04807120000i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D 04807120000i[CPU0 ] | CS:f000( 1e00| 0| 0) 000f0000 0000ffff 0 0 04807120000i[CPU0 ] | DS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 04807120000i[CPU0 ] | SS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 04807120000i[CPU0 ] | ES:0000( 0000| 0| 0) 00000000 0000ffff 0 0 04807120000i[CPU0 ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 04807120000i[CPU0 ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 04807120000i[CPU0 ] | MSR_FS_BASE:0000000000000000 04807120000i[CPU0 ] | MSR_GS_BASE:0000000000000000 04807120000i[CPU0 ] | RIP=0000000000000d72 (0000000000000d72) 04807120000i[CPU0 ] | CR0=0x60000010 CR2=0x0000000000000000 04807120000i[CPU0 ] | CR3=0x00000000 CR4=0x00000000 04807120000i[CPU0 ] >> jmp .+0xfffd (0x000f0d71) : EBFD This is 64bit guet. -- Gleb. |
From: Sebastian H. <he...@gm...> - 2008-11-10 22:09:39
|
Gleb Natapov wrote: > On Mon, Oct 27, 2008 at 12:58:36PM +0200, Stanislav Shwartsman wrote: >> Bochs doesn't support S3 or any other power state, so if you enable it in > Bochs support ACPI and that is almost everything that is needed. I have a patch > for bochs to handle S3, but cpu reset doesn't work for me in current > CVS (reboot from inside a guest doesn't work), so I can't test it. I guess i just wrote a similar patch which sets s.pmsts, calls DEV_cmos_set_reg and tries a call to bx_pc_system.Reset(BX_RESET_HARDWARE) (all in acpi.cc). I think i did stuble on the same cpu reset failure. Log output is 06319290964d[ACPI ] ACPI read from PM register 0x00 returns 0x00000001 06319291103d[ACPI ] ACPI read from PM register 0x00 returns 0x00000001 06319291193d[ACPI ] ACPI write to PM register 0x00, value = 0x8000 06319291340d[ACPI ] ACPI read from PM register 0x00 returns 0x00000001 06319291430d[ACPI ] ACPI write to PM register 0x00, value = 0x8731 06319291687d[ACPI ] ACPI read from PM register 0x04 returns 0x00000001 06319291807d[ACPI ] ACPI write to PM register 0x04, value = 0x0401 06319291943d[ACPI ] ACPI write to PM register 0x04, value = 0x2401 06319291943i[ACPI ] write of 1 to register for S3 06319291943i[SYS ] bx_pc_system_c::Reset(HARDWARE) called 06319291943i[CPU0 ] cpu hardware reset 06319291943i[APIC0] local apic in CPU 0 initializing 06319291943i[ ] reset of ' biosdev' plugin device by virtual method 06319291943i[ ] reset of 'harddrv' plugin device by virtual method 06319291943i[ ] reset of 'keyboard' plugin device by virtual method 06319291943i[ ] reset of 'serial' plugin device by virtual method 06319291943i[ ] reset of 'parallel' plugin device by virtual method 06319291943i[ ] reset of 'extfpuirq' plugin device by virtual method 06319291943i[ ] reset of 'speaker' plugin device by virtual method 06319291943i[ ] reset of 'pci_ide' plugin device by virtual method 06319291943i[ ] reset of 'acpi' plugin device by virtual method 06319291945e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff] 06319291947e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff] I was able to also reproduce the problem by pressing "reset" in the gui while loading the linux kernel (booting rescue label from debian-40r1-i386-businesscard.iso). It did not trigger reliable but did from time to time. Stanislav, any clue what's going on here? - Sebastian |
From: Stanislav S. <stl...@gm...> - 2008-11-11 06:20:15
|
Not from debug print :( It prints that CPU is out of CS limits so probably you running in bogus memory or just the code segment became too big. Stanislav -----Original Message----- From: Sebastian Herbszt [mailto:he...@gm...] Sent: Tuesday, November 11, 2008 12:09 AM To: Gleb Natapov; Stanislav Shwartsman Cc: boc...@li... Subject: Re: [Bochs-developers] [PATCH 3/6] Disable init of SMM. Gleb Natapov wrote: > On Mon, Oct 27, 2008 at 12:58:36PM +0200, Stanislav Shwartsman wrote: >> Bochs doesn't support S3 or any other power state, so if you enable it in > Bochs support ACPI and that is almost everything that is needed. I have a patch > for bochs to handle S3, but cpu reset doesn't work for me in current > CVS (reboot from inside a guest doesn't work), so I can't test it. I guess i just wrote a similar patch which sets s.pmsts, calls DEV_cmos_set_reg and tries a call to bx_pc_system.Reset(BX_RESET_HARDWARE) (all in acpi.cc). I think i did stuble on the same cpu reset failure. Log output is 06319290964d[ACPI ] ACPI read from PM register 0x00 returns 0x00000001 06319291103d[ACPI ] ACPI read from PM register 0x00 returns 0x00000001 06319291193d[ACPI ] ACPI write to PM register 0x00, value = 0x8000 06319291340d[ACPI ] ACPI read from PM register 0x00 returns 0x00000001 06319291430d[ACPI ] ACPI write to PM register 0x00, value = 0x8731 06319291687d[ACPI ] ACPI read from PM register 0x04 returns 0x00000001 06319291807d[ACPI ] ACPI write to PM register 0x04, value = 0x0401 06319291943d[ACPI ] ACPI write to PM register 0x04, value = 0x2401 06319291943i[ACPI ] write of 1 to register for S3 06319291943i[SYS ] bx_pc_system_c::Reset(HARDWARE) called 06319291943i[CPU0 ] cpu hardware reset 06319291943i[APIC0] local apic in CPU 0 initializing 06319291943i[ ] reset of ' biosdev' plugin device by virtual method 06319291943i[ ] reset of 'harddrv' plugin device by virtual method 06319291943i[ ] reset of 'keyboard' plugin device by virtual method 06319291943i[ ] reset of 'serial' plugin device by virtual method 06319291943i[ ] reset of 'parallel' plugin device by virtual method 06319291943i[ ] reset of 'extfpuirq' plugin device by virtual method 06319291943i[ ] reset of 'speaker' plugin device by virtual method 06319291943i[ ] reset of 'pci_ide' plugin device by virtual method 06319291943i[ ] reset of 'acpi' plugin device by virtual method 06319291945e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff] 06319291947e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff] I was able to also reproduce the problem by pressing "reset" in the gui while loading the linux kernel (booting rescue label from debian-40r1-i386-businesscard.iso). It did not trigger reliable but did from time to time. Stanislav, any clue what's going on here? - Sebastian |
From: Stanislav S. <stl...@gm...> - 2008-11-12 06:09:36
|
I don't see any difference between two states you print. So I could assume only one thing - after reset you still have trace cache full with stuff from previous time and you somehow execute hit stale entry and execute it after reset. Flushing the icache and invalidate_prefetch_q() should help here if this is the problem. But still it would be better if I could reproduce myself it somehow ... Does it happen with any livecd UNIX image ? Stanislav -----Original Message----- From: Sebastian Herbszt [mailto:he...@gm...] Sent: Wednesday, November 12, 2008 1:00 AM To: Stanislav Shwartsman; 'Gleb Natapov' Cc: boc...@li... Subject: Re: [Bochs-developers] [PATCH 3/6] Disable init of SMM. Stanislav Shwartsman wrote: > Not from debug print :( > It prints that CPU is out of CS limits so probably you running in bogus > memory or just the code segment became too big. As far as i understand bx_pc_system_c::Reset() it should put the CPU in the same state as power on by calling BX_CPU_C::reset(). So if i call it somewhere in Bochs the CPU should start executing the BIOS again. When i start Bochs i get the following CPU state: 00000000000i[CPU0 ] CPU is in real mode (active) 00000000000i[CPU0 ] CS.d_b = 16 bit 00000000000i[CPU0 ] SS.d_b = 16 bit 00000000000i[CPU0 ] | EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000683 00000000000i[CPU0 ] | ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 00000000000i[CPU0 ] | IOPL=0 id vip vif ac vm rf nt of df if tf sf zf af pf cf 00000000000i[CPU0 ] | SEG selector base limit G D 00000000000i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D 00000000000i[CPU0 ] | CS:f000( 1e00| 0| 0) ffff0000 0000ffff 0 0 00000000000i[CPU0 ] | DS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00000000000i[CPU0 ] | SS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00000000000i[CPU0 ] | ES:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00000000000i[CPU0 ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00000000000i[CPU0 ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00000000000i[CPU0 ] | EIP=0000fff0 (0000fff0) 00000000000i[CPU0 ] | CR0=0x60000010 CR2=0x00000000 00000000000i[CPU0 ] | CR3=0x00000000 CR4=0x00000000 If i press the reset button while the linux kernel is starting and let it end simulation on CPU BX_ERROR() i get 00446059986e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff] or 00354300004e[CPU0 ] branch_near32: offset outside of CS limits or other errors and the CPU state looks like 00446060000i[CPU0 ] CPU is in real mode (active) 00446060000i[CPU0 ] CS.d_b = 16 bit 00446060000i[CPU0 ] SS.d_b = 16 bit 00446060000i[CPU0 ] | EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000683 00446060000i[CPU0 ] | ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 00446060000i[CPU0 ] | IOPL=0 id vip vif ac vm rf nt of df if tf sf ZF af PF cf 00446060000i[CPU0 ] | SEG selector base limit G D 00446060000i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D 00446060000i[CPU0 ] | CS:f000( 1e00| 0| 0) 000f0000 0000ffff 0 0 00446060000i[CPU0 ] | DS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00446060000i[CPU0 ] | SS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00446060000i[CPU0 ] | ES:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00446060000i[CPU0 ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00446060000i[CPU0 ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00446060000i[CPU0 ] | EIP=0000ffff (0000ffff) 00446060000i[CPU0 ] | CR0=0x60000010 CR2=0x00000000 00446060000i[CPU0 ] | CR3=0x00000000 CR4=0x00000000 00446060000i[CPU0 ] (instruction unavailable) page split instruction Gleb, does the CPU state look similar when you experience CPU reset failures? - Sebastian |
From: Sebastian H. <he...@gm...> - 2008-11-12 21:58:30
|
Stanislav Shwartsman wrote: > I don't see any difference between two states you print. 00000000000i[CPU0 ] | CS:f000( 1e00| 0| 0) ffff0000 0000ffff 0 0 and 00446060000i[CPU0 ] | CS:f000( 1e00| 0| 0) 000f0000 0000ffff 0 0 The base value differs. > So I could assume only one thing - after reset you still have trace cache > full with stuff from previous time and you somehow execute hit stale entry > and execute it after reset. Flushing the icache and invalidate_prefetch_q() > should help here if this is the problem. > But still it would be better if I could reproduce myself it somehow ... > Does it happen with any livecd UNIX image ? I was able to reproduce it with openSUSE-10.2-GM-i386-mini.iso, grml_small_0.4.iso and debian-40r1-i386-businesscard.iso (36 MB). You can get the last one from http://iso.linux.hr/debian/current/i386/iso-cd/ . Just start it up and as soon as it prints "Uncompressing Linux..." wait about two seconds and press the reset button. The output is 00282000000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8 00296960000i[WGUI ] system RESET callback 00296960000i[SYS ] bx_pc_system_c::Reset(HARDWARE) called 00296960000i[CPU0 ] cpu hardware reset 00296960000i[APIC0] local apic in CPU 0 initializing 00296960000i[ ] reset of ' biosdev' plugin device by virtual method 00296960000i[ ] reset of 'harddrv' plugin device by virtual method 00296960000i[ ] reset of 'keyboard' plugin device by virtual method 00296960000i[ ] reset of 'serial' plugin device by virtual method 00296960000i[ ] reset of 'parallel' plugin device by virtual method 00296960000i[ ] reset of 'extfpuirq' plugin device by virtual method 00296960000i[ ] reset of 'speaker' plugin device by virtual method 00296960000i[ ] reset of 'pci_ide' plugin device by virtual method 00296960000i[ ] reset of 'acpi' plugin device by virtual method 00296960003e[CPU0 ] branch_near32: offset outside of CS limits 00296960007e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff] 00296960009e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff] - Sebastian |
From: Stanislav S. <stl...@gm...> - 2008-11-13 19:16:57
|
I hope you use CVS version ? We once had very similar issue and AFAIR it was fixed once already :) I'll check it. Stanislav -----Original Message----- From: Sebastian Herbszt [mailto:he...@gm...] Sent: Wednesday, November 12, 2008 11:58 PM To: Stanislav Shwartsman; 'Gleb Natapov' Cc: boc...@li... Subject: Re: [Bochs-developers] [PATCH 3/6] Disable init of SMM. Stanislav Shwartsman wrote: > I don't see any difference between two states you print. 00000000000i[CPU0 ] | CS:f000( 1e00| 0| 0) ffff0000 0000ffff 0 0 and 00446060000i[CPU0 ] | CS:f000( 1e00| 0| 0) 000f0000 0000ffff 0 0 The base value differs. > So I could assume only one thing - after reset you still have trace cache > full with stuff from previous time and you somehow execute hit stale entry > and execute it after reset. Flushing the icache and invalidate_prefetch_q() > should help here if this is the problem. > But still it would be better if I could reproduce myself it somehow ... > Does it happen with any livecd UNIX image ? I was able to reproduce it with openSUSE-10.2-GM-i386-mini.iso, grml_small_0.4.iso and debian-40r1-i386-businesscard.iso (36 MB). You can get the last one from http://iso.linux.hr/debian/current/i386/iso-cd/ . Just start it up and as soon as it prints "Uncompressing Linux..." wait about two seconds and press the reset button. The output is 00282000000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8 00296960000i[WGUI ] system RESET callback 00296960000i[SYS ] bx_pc_system_c::Reset(HARDWARE) called 00296960000i[CPU0 ] cpu hardware reset 00296960000i[APIC0] local apic in CPU 0 initializing 00296960000i[ ] reset of ' biosdev' plugin device by virtual method 00296960000i[ ] reset of 'harddrv' plugin device by virtual method 00296960000i[ ] reset of 'keyboard' plugin device by virtual method 00296960000i[ ] reset of 'serial' plugin device by virtual method 00296960000i[ ] reset of 'parallel' plugin device by virtual method 00296960000i[ ] reset of 'extfpuirq' plugin device by virtual method 00296960000i[ ] reset of 'speaker' plugin device by virtual method 00296960000i[ ] reset of 'pci_ide' plugin device by virtual method 00296960000i[ ] reset of 'acpi' plugin device by virtual method 00296960003e[CPU0 ] branch_near32: offset outside of CS limits 00296960007e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff] 00296960009e[CPU0 ] prefetch: EIP [00010000] > CS.limit [0000ffff] - Sebastian |
From: Sebastian H. <he...@gm...> - 2008-11-13 20:00:49
|
Stanislav Shwartsman wrote: > I hope you use CVS version ? We once had very similar issue and AFAIR it was > fixed once already :) > I'll check it. The log i posted was created by bochs build from yesterdays cvs snapshot. 00000000000i[ ] Bochs x86 Emulator 2.3.7.cvs 00000000000i[ ] Build from CVS snapshot, after release 2.3.7 00000000000i[ ] System configuration 00000000000i[ ] processors: 1 (cores=1, HT threads=1) 00000000000i[ ] A20 line support: yes 00000000000i[ ] APIC support: yes 00000000000i[ ] CPU configuration 00000000000i[ ] level: 6 00000000000i[ ] SMP support: no 00000000000i[ ] FPU support: yes 00000000000i[ ] MMX support: yes 00000000000i[ ] SSE support: no 00000000000i[ ] CLFLUSH support: no 00000000000i[ ] VME support: yes 00000000000i[ ] 3dnow! support: no 00000000000i[ ] PAE support: yes 00000000000i[ ] PGE support: yes 00000000000i[ ] PSE support: yes 00000000000i[ ] x86-64 support: no 00000000000i[ ] SEP support: yes 00000000000i[ ] MWAIT support: no 00000000000i[ ] XSAVE support: no 00000000000i[ ] AES support: no 00000000000i[ ] Optimization configuration 00000000000i[ ] Guest2HostTLB support: yes 00000000000i[ ] RepeatSpeedups support: yes 00000000000i[ ] Icache support: yes 00000000000i[ ] Trace cache support: yes 00000000000i[ ] Fast function calls: yes 00000000000i[ ] Devices configuration 00000000000i[ ] ACPI support: yes 00000000000i[ ] NE2000 support: no 00000000000i[ ] PCI support: yes 00000000000i[ ] SB16 support: no 00000000000i[ ] USB support: no 00000000000i[ ] VGA extension support: vbe - Sebastian |
From: Stanislav S. <stl...@gm...> - 2008-11-13 23:06:39
|
Just fixed the issue. Again :) Thanks, Stanislav -----Original Message----- From: Sebastian Herbszt [mailto:he...@gm...] Sent: Thursday, November 13, 2008 10:00 PM To: Stanislav Shwartsman; 'Gleb Natapov' Cc: boc...@li... Subject: Re: [Bochs-developers] [PATCH 3/6] Disable init of SMM. Stanislav Shwartsman wrote: > I hope you use CVS version ? We once had very similar issue and AFAIR it was > fixed once already :) > I'll check it. The log i posted was created by bochs build from yesterdays cvs snapshot. 00000000000i[ ] Bochs x86 Emulator 2.3.7.cvs 00000000000i[ ] Build from CVS snapshot, after release 2.3.7 00000000000i[ ] System configuration 00000000000i[ ] processors: 1 (cores=1, HT threads=1) 00000000000i[ ] A20 line support: yes 00000000000i[ ] APIC support: yes 00000000000i[ ] CPU configuration 00000000000i[ ] level: 6 00000000000i[ ] SMP support: no 00000000000i[ ] FPU support: yes 00000000000i[ ] MMX support: yes 00000000000i[ ] SSE support: no 00000000000i[ ] CLFLUSH support: no 00000000000i[ ] VME support: yes 00000000000i[ ] 3dnow! support: no 00000000000i[ ] PAE support: yes 00000000000i[ ] PGE support: yes 00000000000i[ ] PSE support: yes 00000000000i[ ] x86-64 support: no 00000000000i[ ] SEP support: yes 00000000000i[ ] MWAIT support: no 00000000000i[ ] XSAVE support: no 00000000000i[ ] AES support: no 00000000000i[ ] Optimization configuration 00000000000i[ ] Guest2HostTLB support: yes 00000000000i[ ] RepeatSpeedups support: yes 00000000000i[ ] Icache support: yes 00000000000i[ ] Trace cache support: yes 00000000000i[ ] Fast function calls: yes 00000000000i[ ] Devices configuration 00000000000i[ ] ACPI support: yes 00000000000i[ ] NE2000 support: no 00000000000i[ ] PCI support: yes 00000000000i[ ] SB16 support: no 00000000000i[ ] USB support: no 00000000000i[ ] VGA extension support: vbe - Sebastian |
From: Sebastian H. <he...@gm...> - 2008-11-14 17:40:21
|
Stanislav Shwartsman wrote: > Just fixed the issue. Again :) Seems to work for me too. Thanks. Being able to reset did uncover an issue with the IO-APIC. More on this in a separate mail. - Sebastian |