On 13.09.2011, at 10:14, Jan Kiszka wrote: On 2011-09-13 09:39, Alexander Graf wrote:
On 12.09.2011, at 17:57, Jan Kiszka wrote:
On 2011-09-12 17:49, Jan Kiszka wrote:
On 2011-09-12 17:45, Andreas Färber wrote:
Am 12.09.2011 17:33, schrieb Jan Kiszka:
On 2011-09-12 17:20, Alexander Graf wrote:
Jan Kiszka wrote:
Most VGA memory access modes require MMIO handling as they demand weird
logic to get a byte from or into the video RAM. However, there is one
exception: chain 4 mode with all memory planes enabled for writing. This
mode actually allows lineary mapping, which can then be combined with
dirty logging to accelerate KVM.
This patch accelerates specifically VBE accesses like they are used by
grub in graphical mode. Not only the standard VGA adapter benefits from
this, also vmware and spice in VGA mode.
CC: Gerd Hoffmann <address@hidden>
CC: Avi Kivity <address@hidden>
Signed-off-by: Jan Kiszka <address@hidden>
[...]
+static void vga_update_memory_access(VGACommonState *s)
+{
+ MemoryRegion *region, *old_region = s->chain4_alias;
+ target_phys_addr_t base, offset, size;
+
+ s->chain4_alias = NULL;
+
+ if ((s->sr[0x02] & 0xf) == 0xf && s->sr[0x04] & 0x08) {
+ offset = 0;
+ switch ((s->gr[6] >> 2) & 3) {
+ case 0:
+ base = 0xa0000;
+ size = 0x20000;
+ break;
+ case 1:
+ base = 0xa0000;
+ size = 0x10000;
+ offset = s->bank_offset;
+ break;
+ case 2:
+ base = 0xb0000;
+ size = 0x8000;
+ break;
+ case 3:
+ base = 0xb8000;
+ size = 0x8000;
+ break;
+ }
+ region = g_malloc(sizeof(*region));
+ memory_region_init_alias(region, "vga.chain4", &s->vram, offset, size);
+ memory_region_add_subregion_overlap(s->legacy_address_space, base,
+ region, 2);
This one eventually gives me the following in info mtree with -M g3beige
on qemu-system-ppc:
(qemu) info mtree
memory
system addr 00000000 off 00000000 size 7fffffffffffffff
-vga.chain4 addr 000a0000 off 00000000 size 10000
-macio addr 80880000 off 00000000 size 80000
--macio-nvram addr 00060000 off 00000000 size 20000
--pmac-ide addr 00020000 off 00000000 size 1000
--cuda addr 00016000 off 00000000 size 2000
--escc-bar addr 00013000 off 00000000 size 40
--dbdma addr 00008000 off 00000000 size 1000
--heathrow-pic addr 00000000 off 00000000 size 1000
-vga.rom addr 80800000 off 00000000 size 10000
-vga.vram addr 80000000 off 00000000 size 800000
-vga-lowmem addr 800a0000 off 00000000 size 20000
-escc addr 80013000 off 00000000 size 40
-isa-mmio addr fe000000 off 00000000 size 200000
I/O
io addr 00000000 off 00000000 size 10000
-cmd646-bmdma addr 00000700 off 00000000 size 10
--cmd646-bmdma-ioport addr 0000000c off 00000000 size 4
--cmd646-bmdma-bus addr 00000008 off 00000000 size 4
--cmd646-bmdma-ioport addr 00000004 off 00000000 size 4
--cmd646-bmdma-bus addr 00000000 off 00000000 size 4
-cmd646-cmd addr 00000680 off 00000000 size 4
-cmd646-data addr 00000600 off 00000000 size 8
-cmd646-cmd addr 00000580 off 00000000 size 4
-cmd646-data addr 00000500 off 00000000 size 8
-ne2000 addr 00000400 off 00000000 size 100
This ends up overmapping 0xa0000, effectively overwriting kernel data.
If I #if 0 the offending chunk out, everything is fine. I would assume
that chain4 really needs to be inside of lowmem? No idea about VGA, but
I'm sure you know what's going on :).
Does this help?
diff --git a/hw/vga.c b/hw/vga.c
index 125fb29..0a0c5a6 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -181,6 +181,7 @@ static void vga_update_memory_access(VGACommonState *s)
size = 0x8000;
break;
}
+ base += isa_mem_base;
region = g_malloc(sizeof(*region));
memory_region_init_alias(region, "vga.chain4", &s->vram, offset, size);
memory_region_add_subregion_overlap(s->legacy_address_space, base,
No longer oopses, but the screen looks chaotic now (black bar at bottom,
part of contents at top etc.).
Does this PPC machine map the ISA range and forward VGA accesses to the
adapter in general?
If it does, please post a dump of the VGACommonState while the screen is
corrupted (gdb or via device_show [1]. Maybe I missed some condition
that prevents chain4 optimizations, and your guest triggers this.
Picture: http://dl.dropbox.com/u/8976842/qemu/Screen%20shot%202011-09-13%20at%2009.37.15.png
(qemu) info qtree
bus: main-system-bus
type System
dev: fw_cfg, id "#8"
dev-prop: ctl_iobase = 0x0
dev-prop: data_iobase = 0x0
irq 0
mmio f0000510/00000002
mmio f0000512/00000002
dev: escc, id "#4"
dev-prop: frequency = 3686400
dev-prop: it_shift = 4
dev-prop: disabled = 0
dev-prop: disabled = 0
dev-prop: chnBtype = 0
dev-prop: chnAtype = 0
dev-prop: chrB = <null>
dev-prop: chrA = serial0
irq 2
mmio 80013000/00000040
dev: grackle, id "#1"
irq 0
mmio fec00000/00001000
mmio fee00000/00001000
bus: pci
type PCI
dev: cmd646-ide, id "#6"
dev-prop: secondary = 0
bus-prop: addr = 03.0
bus-prop: romfile = <null>
bus-prop: rombar = 1
bus-prop: multifunction = off
bus-prop: command_serr_enable = on
class IDE controller, addr 00:03.0, pci id 1095:0646 (sub 1af4:1100)
bar 0: i/o at 0x500 [0x507]
bar 1: i/o at 0x580 [0x583]
bar 2: i/o at 0x600 [0x607]
bar 3: i/o at 0x680 [0x683]
bar 4: i/o at 0x700 [0x70f]
bus: ide.1
type IDE
bus: ide.0
type IDE
dev: ide-cd, id "#7"
dev-prop: drive = ide1-cd0
dev-prop: logical_block_size = 512
dev-prop: physical_block_size = 512
dev-prop: min_io_size = 0
dev-prop: opt_io_size = 0
dev-prop: bootindex = -1
dev-prop: discard_granularity = 0
dev-prop: ver = "0.15.50"
dev-prop: serial = "QM00003"
bus-prop: unit = 0
dev: ne2k_pci, id "#5"
dev-prop: mac = 52:54:00:12:34:56
dev-prop: vlan = 0
dev-prop: netdev = <null>
dev-prop: bootindex = -1
bus-prop: addr = 02.0
bus-prop: romfile = <null>
bus-prop: rombar = 1
bus-prop: multifunction = off
bus-prop: command_serr_enable = on
class Ethernet controller, addr 00:02.0, pci id 10ec:8029 (sub 1af4:1100)
bar 0: i/o at 0x400 [0x4ff]
dev: VGA, id "#3"
bus-prop: addr = 01.0
bus-prop: romfile = "vgabios-stdvga.bin"
bus-prop: rombar = 1
bus-prop: multifunction = off
bus-prop: command_serr_enable = on
class VGA controller, addr 00:01.0, pci id 1234:1111 (sub 1af4:1100)
bar 0: mem at 0x80000000 [0x807fffff]
bar 6: mem at 0x80800000 [0x8080ffff]
dev: grackle, id "#2"
bus-prop: addr = 00.0
bus-prop: romfile = <null>
bus-prop: rombar = 1
bus-prop: multifunction = off
bus-prop: command_serr_enable = on
class Host bridge, addr 00:00.0, pci id 1057:0002 (sub 1af4:1100)
(qemu) device_show #3
dev: VGA, id "#3", version 2
dev.
version_id: 00000002
config: 00 00 00 00 10 d1 cf 20 - 00 00 00 00 10 d1 d0 30
...
irq_state: 00 00 00 00 00 00 00 10 - 00 00 00 00 00 00 00 00
vga.
latch: 00000000
sr_index: 00
sr: 00 00 0f 00 08 00 00 00
gr_index: 00
gr: 00 00 00 00 00 40 05 00 - 00 00 00 00 00 00 00 00
ar_index: 20
ar: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
...
ar_flip_flop: 00000001
cr_index: 00
cr: 00 63 00 00 00 00 00 50 - 00 40 00 00 00 00 00 00
...
msr: 00
fcr: 00
st00: 00
st01: 00
dac_state: 00
dac_sub_index: 00
dac_read_index: 00
dac_write_index: 10
dac_cache: 3f 3f 3f
palette: 00 00 00 00 00 2a 00 2a - 00 00 2a 2a 2a 00 00 2a
...
bank_offset: 00000000
is_vbe_vmstate: 01
vbe_index: 0004
vbe_regs[00]: b0c5
vbe_regs[01]: 0320
vbe_regs[02]: 0258
vbe_regs[03]: 000f
vbe_regs[04]: 0001
vbe_regs[05]: 0000
vbe_regs[06]: 0320
vbe_regs[07]: 0258
vbe_regs[08]: 0000
vbe_regs[09]: 0000
vbe_start_addr: 00000000
vbe_line_offset: 00000640
vbe_bank_mask: 0000007f
Makes no sense, must work with this setup. Maybe it's dynamic effect when switching modes of bank offsets. Do you have some test image for me?
No need for an image - the black bar already occurs in firmware. If you want to check that everything really does work, Aurelien has a great collection of QEMU Debian images:
Thanks for looking into this :)
Alex
|
