Clear bios framebuffer with minimal writes

PATCH In review Ben Guthro 3 participants 6 messages Oct 24, 2007 – Oct 30, 2007

lore

Share & tools

lore

Ben Guthro

author

2007-10-24 21:04 UTC #0 lore raw

PATCH 1/1 Clear bios framebuffer with minimal writes

Support for VGA bios to clear framebuffer with minimal writes.

Signed-off-by Ben Guthro <[email protected]>

Signed-off-by Gary Grebus <[email protected]>

tools/firmware/hvmloader/Makefile +3 -3

diff -r abca07dac924 tools/firmware/hvmloader/Makefile
@@ -51,10 +51,10 @@ acpi/acpi.a:
 acpi/acpi.a:
 	$(MAKE) -C acpi
 
-roms.h:	../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../vmxassist/vmxassist.bin ../etherboot/eb-rtl8139.zrom.h
+roms.h:	../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest$(DEBUG_ROM).bin ../vgabios/VGABIOS-lgpl-latest.cirrus$(DEBUG_ROM).bin ../vmxassist/vmxassist.bin ../etherboot/eb-rtl8139.zrom.h
 	sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
-	sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >> roms.h
-	sh ./mkhex vgabios_cirrusvga ../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
+	sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest$(DEBUG_ROM).bin >> roms.h
+	sh ./mkhex vgabios_cirrusvga ../vgabios/VGABIOS-lgpl-latest.cirrus$(DEBUG_ROM).bin >> roms.h
 	sh ./mkhex vmxassist ../vmxassist/vmxassist.bin >> roms.h
 	cat ../etherboot/eb-rtl8139.zrom.h >> roms.h

tools/firmware/vgabios/clext.c +21 -9

diff -r abca07dac924 tools/firmware/vgabios/clext.c
@@ -1489,19 +1489,31 @@ cirrus_clear_vram_1:
   mov dx, #0x3ce
   out dx, ax
   push ax
-  mov cx, #0xa000
-  mov es, cx
-  xor di, di
+
+;; Windows Vista appears to be emulating this sequence as part of changing 
+;; screen resolution, but it generates 4096 writes per iteration.
+;; Instead, use a magic register sequence to write the whole bank.
+;; to avoid 
+;;mov cx, #0xa000
+;;mov es, cx
+;;xor di, di
+;;mov ax, si
+;;mov cx, #8192
+;;cld
+;;rep
+;;    stosw
   mov ax, si
-  mov cx, #8192
-  cld
-  rep
-      stosw
+  shl ax, #8
+  mov al, #0xfe
+  out dx, ax	;; Low byte of value to be written to the bank
+  mov ax, si
+  mov al, #0xff  
+  out dx, ax    ;; High byte and trigger the write
+
   pop ax
   inc ah
   cmp ah, bl
   jne cirrus_clear_vram_1
-
   pop es
   popa
   ret

@@ -1628,6 +1640,6 @@ static void cirrus_debugmsg(DI, SI, BP, 
   Bit16u DI, SI, BP, SP, BX, DX, CX, AX, ES, DS, FLAGS;
 {
  if((GET_AH()!=0x0E)&&(GET_AH()!=0x02)&&(GET_AH()!=0x09)&&(AX!=0x4F05))
-  printf("vgabios call ah%02x al%02x bx%04x cx%04x dx%04x\n",GET_AH(),GET_AL(),BX,CX,DX);
+  printf("cirrusbios call ah%02x al%02x bx%04x cx%04x dx%04x\n",GET_AH(),GET_AL(),BX,CX,DX);
 }
 #endif

tools/ioemu/hw/cirrus_vga.c +12 -0

diff -r abca07dac924 tools/ioemu/hw/cirrus_vga.c
@@ -294,6 +294,7 @@ void *shared_vram;
 
 static void cirrus_bitblt_reset(CirrusVGAState *s);
 static void cirrus_update_memory_access(CirrusVGAState *s);
+static void cirrus_vga_mem_writew(void *opaque, target_phys_addr_t addr, uint32_t val);
 
 /***************************************
  *

@@ -1497,6 +1498,17 @@ cirrus_hook_write_gr(CirrusVGAState * s,
     case 0x31:			// BLT STATUS/START
 	cirrus_write_bitblt(s, reg_value);
 	break;
+
+	// Extension to allow BIOS to clear 16K VRAM bank in one operation
+    case 0xFE:
+	s->gr[reg_index] = reg_value;  // Lower byte of value to be written
+	break;
+    case 0xFF: {
+	target_phys_addr_t addr;
+	for (addr = 0xa0000; addr < 0xa4000; addr+=2)
+	    cirrus_vga_mem_writew(s, addr, (reg_value << 8) | s->gr[0xFE]);
+        }
+	break;
     default:
 #ifdef DEBUG_CIRRUS
 	printf("cirrus: outport gr_index %02x, gr_value %02x\n", reg_index,

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2007-10-25 14:20 UTC #1 lore raw

Quoted 4 lines · Ben Guthro

Support for VGA bios to clear framebuffer with minimal writes.
Signed-off-by Ben Guthro <[email protected]>
Signed-off-by Gary Grebus <[email protected]>

Is this really just a workaround for the insane-sounding case of Vista clearing the screen, as described in one of the comments? Do I understand correctly, and it looks like Vista does 4096 writes for each iteration of the rep stosw?

-- Keir

Gary Grebus

2007-10-25 15:23 UTC #2 lore raw

Quoted 11 lines · Keir Fraser

Quoted 4 lines · Ben Guthro
Support for VGA bios to clear framebuffer with minimal writes.
Signed-off-by Ben Guthro <[email protected]>
Signed-off-by Gary Grebus <[email protected]>
Is this really just a workaround for the insane-sounding case of Vista clearing the screen, as described in one of the comments? Do I understand correctly, and it looks like Vista does 4096 writes for each iteration of the rep stosw?

Yep. This happens when resizing the screen in Vista. It appears to do this by executing the VGA BIOS code in some sort of emulation, and the BIOS function to clear the screen (which uses a rep stosw) gets emulated as 4096 separate writes.

This is so slow that occasionally some watchdog timer in Vista (that was timing the BIOS emulation) would expire and cause a blue screen.

This fix was a bit of a hack. It might be possible to speed up VGA writes enough to make this unnecessary, but that was more of a challenge than I wanted at the time.

/gary

Signature · 2 lines

Gary Grebus
Virtual Iron Software, Inc.

Keir Fraser

2007-10-25 15:34 UTC #3 lore raw

Quoted 10 lines · Gary Grebus

Quoted 4 lines
Is this really just a workaround for the insane-sounding case of Vista clearing the screen, as described in one of the comments? Do I understand correctly, and it looks like Vista does 4096 writes for each iteration of the rep stosw?
Yep. This happens when resizing the screen in Vista. It appears to do this by executing the VGA BIOS code in some sort of emulation, and the BIOS function to clear the screen (which uses a rep stosw) gets emulated as 4096 separate writes.

Quoted 6 lines

This is so slow that occasionally some watchdog timer in Vista (that was timing the BIOS emulation) would expire and cause a blue screen.
This fix was a bit of a hack. It might be possible to speed up VGA writes enough to make this unnecessary, but that was more of a challenge than I wanted at the time.

Ugh, that is awkward. Did you do this hack before the stdvga emulation-in-xen and buffered-io patch that you guys also sent out today? I wonder whether that speeds up vga writes enough, or whether you needed this hack despite the speedups that other patch achieved? Overall, I guess I'm not against this patch even though it is a bit sleazy. :-) But obviously it's even better if the problem goes away by other means...

-- Keir

Gary Grebus

2007-10-25 17:14 UTC #4 lore raw

Quoted 7 lines · Keir Fraser

Ugh, that is awkward. Did you do this hack before the stdvga emulation-in-xen and buffered-io patch that you guys also sent out today? I wonder whether that speeds up vga writes enough, or whether you needed this hack despite the speedups that other patch achieved? Overall, I guess I'm not against this patch even though it is a bit sleazy. :-) But obviously it's even better if the problem goes away by other means...

This patch predates the stdvga emulation-in-xen and buffered-io changes. I'll try with only the later changes and see if they are sufficient.

/gary

Signature · 2 lines

Gary Grebus
Virtual Iron Software, Inc.

Gary Grebus

2007-10-30 17:52 UTC #5 lore raw

Quoted 10 lines · Gary Grebus

Quoted 7 lines · Keir Fraser
Ugh, that is awkward. Did you do this hack before the stdvga emulation-in-xen and buffered-io patch that you guys also sent out today? I wonder whether that speeds up vga writes enough, or whether you needed this hack despite the speedups that other patch achieved? Overall, I guess I'm not against this patch even though it is a bit sleazy. :-) But obviously it's even better if the problem goes away by other means...

Quoted 3 lines

This patch predates the stdvga emulation-in-xen and buffered-io changes. I'll try with only the later changes and see if they are sufficient.

I tried with only the stdvga and buffered-io patch. Things got worse, to the point that Vista no longer boots, encountering a BSOD due to a timeout in Vista graphics driver.

Apparently the stdvga and buffered-io patch de-optimizes this particular case, but we didn't notice due to the vgabios patch.

The vgabios patch fixes the intermittent "BSOD on screen resize" problem either way. We won't know if it's really necessary until we can fix the stdvga etc. patch which at the moment looks a little suspect.

/gary