vga: dirty log cleanup, more linear mapping

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.

Quoted 6 lines · Jan Kiszka

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.

Quoted 5 lines

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.

On which version of grub does this work? This isn't having any effect on my Fedora grub.

Quoted 4 lines

Quoted 1 line

On which version of grub does this work? This isn't having any effect on my Fedora grub.

It's both grub1 (0.97) in graphical mode as used by OpenSUSE 11.4 and grub2 (1.99-rc1) of Ubuntu 11.04.

Is Fedora's grub still slow or was it already fast before? Which Fedora?

Quoted 8 lines · Jan Kiszka

Quoted 4 lines

Quoted 1 line

On which version of grub does this work? This isn't having any effect on my Fedora grub.

It's both grub1 (0.97) in graphical mode as used by OpenSUSE 11.4 and grub2 (1.99-rc1) of Ubuntu 11.04.

Quoted 2 lines

Is Fedora's grub still slow or was it already fast before? Which Fedora?

Still slow. I tried an old F11 image I had lying around, and -snapshot /dev/sda, but this laptop was installed many years ago. I'll download some more images and try.

Quoted 4 lines

Still slow. I tried an old F11 image I had lying around, and -snapshot /dev/sda, but this laptop was installed many years ago. I'll download some more images and try.

You may also want to instrument vga_update_memory_access if some requirement for linear mapping is not fulfilled.

Quoted 8 lines · Jan Kiszka

Quoted 4 lines

Still slow. I tried an old F11 image I had lying around, and -snapshot /dev/sda, but this laptop was installed many years ago. I'll download some more images and try.

You may also want to instrument vga_update_memory_access if some requirement for linear mapping is not fulfilled.

Plain F15 is slow. SR2 = SR4 = 0.

Quoted 2 lines

Plain F15 is slow. SR2 = SR4 = 0.

So it's not using chain4 mode. Can you check what mode the adapter is actually in and how VRAM is accessed? Likely, there is nothing we can do about it. /me just wonders what makes F15 grub behave differently from other distro's versions...

Quoted 8 lines · Jan Kiszka

Quoted 2 lines

Plain F15 is slow. SR2 = SR4 = 0.

So it's not using chain4 mode. Can you check what mode the adapter is actually in and how VRAM is accessed? Likely, there is nothing we can do about it. /me just wonders what makes F15 grub behave differently from other distro's versions...

Do you remember offhand which registers I need to look at?

We need a collection of gdb scripts to find a qdev, dump the memory hierarchy, look up gpas, and get info about specific devices.

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 <[email protected]>

CC Avi Kivity <[email protected]>

Signed-off-by Jan Kiszka <[email protected]>

hw/vga.c +22 -0

+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;

Quoted 14 lines · Jan Kiszka

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 <[email protected]>

CC Avi Kivity <[email protected]>

Signed-off-by Jan Kiszka <[email protected]>

[...]

Quoted 23 lines

(quoted diff) +22 -0

+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;

Review

Quoted 10 lines

(quoted diff) +10 -0

+            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

(quoted diff) +0 -13

-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

(quoted diff) +0 -10

-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 :).

Quoted 82 lines

Quoted 14 lines · Jan Kiszka

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 <[email protected]>

CC Avi Kivity <[email protected]>

Signed-off-by Jan Kiszka <[email protected]>

[...]

Quoted 23 lines

(quoted diff) +22 -0

+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;

Review

Quoted 10 lines

(quoted diff) +10 -0

+            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

(quoted diff) +0 -13

-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

(quoted diff) +0 -10

-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

Quoted 4 lines

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?

hw/vga.c +0 -0

index 125fb29..0a0c5a6 100644

Am 12.09.2011 17:33, schrieb Jan Kiszka:

Quoted 89 lines · Alexander Graf

Quoted 82 lines

Quoted 14 lines · Jan Kiszka

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 <[email protected]>

CC Avi Kivity <[email protected]>

Signed-off-by Jan Kiszka <[email protected]>

[...]

Quoted 23 lines

(quoted diff) +22 -0

+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;

Review

Quoted 10 lines

(quoted diff) +10 -0

+            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

(quoted diff) +0 -13

-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

(quoted diff) +0 -10

-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

Quoted 4 lines

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?

hw/vga.c static void vga_update_memory_access(VGACommonState *s) · line 187

Quoted 12 lines

hw/vga.c +1 -0

index 125fb29..0a0c5a6 100644
@@ -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.).

Quoted 90 lines · Andreas Färber

Am 12.09.2011 17:33, schrieb Jan Kiszka:

Quoted 89 lines · Alexander Graf

Quoted 82 lines

Quoted 14 lines · Jan Kiszka

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 <[email protected]>

CC Avi Kivity <[email protected]>

Signed-off-by Jan Kiszka <[email protected]>

[...]

Quoted 23 lines

(quoted diff) +22 -0

+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;

Review

Quoted 10 lines

(quoted diff) +10 -0

+            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

(quoted diff) +0 -13

-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

(quoted diff) +0 -10

-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

Quoted 4 lines

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?

Quoted 15 lines

hw/vga.c static void vga_update_memory_access(VGACommonState *s) · line 187

Quoted 12 lines

hw/vga.c +1 -0

index 125fb29..0a0c5a6 100644
@@ -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?

Quoted 107 lines · Jan Kiszka

Quoted 105 lines · Andreas Färber

Am 12.09.2011 17:33, schrieb Jan Kiszka:

Quoted 94 lines · Alexander Graf

Quoted 82 lines

Quoted 14 lines · Jan Kiszka

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 <[email protected]>

CC Avi Kivity <[email protected]>

Signed-off-by Jan Kiszka <[email protected]>

[...]

Quoted 23 lines

(quoted diff) +22 -0

+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;

Review

Quoted 10 lines

(quoted diff) +10 -0

+            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

(quoted diff) +0 -13

-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

(quoted diff) +0 -10

-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

Quoted 4 lines

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?

hw/vga.c +0 -0

index 125fb29..0a0c5a6 100644

hw/vga.c static void vga_update_memory_access(VGACommonState *s) · line 187

Quoted 7 lines

hw/vga.c +1 -0

@@ -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.).

Quoted 2 lines

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.

Quoted 108 lines · Jan Kiszka

Quoted 107 lines · Jan Kiszka

Quoted 105 lines · Andreas Färber

Am 12.09.2011 17:33, schrieb Jan Kiszka:

Quoted 94 lines · Alexander Graf

Quoted 82 lines

Quoted 14 lines · Jan Kiszka

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 <[email protected]>

CC Avi Kivity <[email protected]>

Signed-off-by Jan Kiszka <[email protected]>

[...]

Quoted 23 lines

(quoted diff) +22 -0

+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;

Review

Quoted 10 lines

(quoted diff) +10 -0

+            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

(quoted diff) +0 -13

-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

(quoted diff) +0 -10

-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

Quoted 4 lines

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?

hw/vga.c +0 -0

index 125fb29..0a0c5a6 100644

hw/vga.c static void vga_update_memory_access(VGACommonState *s) · line 187

Quoted 7 lines

hw/vga.c +1 -0

@@ -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.).

Quoted 6 lines

Quoted 2 lines

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

Quoted 244 lines · Alexander Graf

Quoted 108 lines · Jan Kiszka

Quoted 107 lines · Jan Kiszka

Quoted 105 lines · Andreas Färber

Am 12.09.2011 17:33, schrieb Jan Kiszka:

Quoted 94 lines · Alexander Graf

Quoted 82 lines

Quoted 14 lines · Jan Kiszka

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 <[email protected]>

CC Avi Kivity <[email protected]>

Signed-off-by Jan Kiszka <[email protected]>

[...]

Quoted 23 lines

(quoted diff) +22 -0

+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;

Review

Quoted 10 lines

(quoted diff) +10 -0

+            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

(quoted diff) +0 -13

-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

(quoted diff) +0 -10

-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

Quoted 4 lines

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?

hw/vga.c +0 -0

index 125fb29..0a0c5a6 100644

hw/vga.c static void vga_update_memory_access(VGACommonState *s) · line 187

Quoted 7 lines

hw/vga.c +1 -0

@@ -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.).

Quoted 6 lines

Quoted 2 lines

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

Quoted 9 lines

   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?

Quoted 45 lines

(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

Quoted 9 lines

   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?

Quoted 244 lines · Alexander Graf

Quoted 108 lines · Jan Kiszka

Quoted 107 lines · Jan Kiszka

Quoted 105 lines · Andreas Färber

Am 12.09.2011 17:33, schrieb Jan Kiszka:

Quoted 94 lines · Alexander Graf

Quoted 82 lines

Quoted 14 lines · Jan Kiszka

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 <[email protected]>

CC Avi Kivity <[email protected]>

Signed-off-by Jan Kiszka <[email protected]>

[...]

Quoted 23 lines

(quoted diff) +22 -0

+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;

Review

Quoted 10 lines

(quoted diff) +10 -0

+            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

(quoted diff) +0 -13

-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

(quoted diff) +0 -10

-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

Quoted 4 lines

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?

hw/vga.c +0 -0

index 125fb29..0a0c5a6 100644

hw/vga.c static void vga_update_memory_access(VGACommonState *s) · line 187

Quoted 7 lines

hw/vga.c +1 -0

@@ -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.).

Quoted 6 lines

Quoted 2 lines

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

Quoted 9 lines

   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?

Btw, it still tries to execute invalid code even with your patch. #if 0'ing out the memory region updates at least get the guest booting for me. Btw, to get it working you also need a patch for the interrupt controller (another breakage thanks to memory api).

hw/heathrow_pic.c +0 -0

index 51996ab..16f48d1 100644

Quoted 14 lines · Alexander Graf

Btw, it still tries to execute invalid code even with your patch. #if 0'ing out the memory region updates at least get the guest booting for me. Btw, to get it working you also need a patch for the interrupt controller (another breakage thanks to memory api).

hw/heathrow_pic.c +1 -1

index 51996ab..16f48d1 100644
@@ -126,7 +126,7 @@ static uint64_t pic_read(void *opaque, target_phys_addr_t addr,
 static const MemoryRegionOps heathrow_pic_ops = {
    .read = pic_read,
    .write = pic_write,
-    .endianness = DEVICE_NATIVE_ENDIAN,
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 

hw/heathrow_pic.c static uint64_t pic_read(void *opaque, target_phys_addr_t addr, · line 132

Quoted 2 lines

hw/heathrow_pic.c +0 -0

 static void heathrow_pic_set_irq(void *opaque, int num, int level)

With out without this fix, with or without active chain-4 optimization, I just get an empty yellow screen when firing up qemu-system-ppc (also when using the Debian ISO). Do I need to specify a specific machine type?

Quoted 15 lines · Jan Kiszka

Quoted 14 lines · Alexander Graf

Btw, it still tries to execute invalid code even with your patch. #if 0'ing out the memory region updates at least get the guest booting for me. Btw, to get it working you also need a patch for the interrupt controller (another breakage thanks to memory api).

hw/heathrow_pic.c +1 -1

index 51996ab..16f48d1 100644
@@ -126,7 +126,7 @@ static uint64_t pic_read(void *opaque, target_phys_addr_t addr,
 static const MemoryRegionOps heathrow_pic_ops = {
    .read = pic_read,
    .write = pic_write,
-    .endianness = DEVICE_NATIVE_ENDIAN,
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 

Quoted 6 lines

hw/heathrow_pic.c static uint64_t pic_read(void *opaque, target_phys_addr_t addr, · line 132

Quoted 2 lines

hw/heathrow_pic.c +0 -0

 static void heathrow_pic_set_irq(void *opaque, int num, int level)

With out without this fix, with or without active chain-4 optimization, I just get an empty yellow screen when firing up qemu-system-ppc (also when using the Debian ISO). Do I need to specify a specific machine type?

Ugh. No, you only need this patch:

[PATCH] PPC: Fix via-cuda memory registration

which fixes another recently introduced regression :)

Quoted 25 lines · Alexander Graf

Quoted 15 lines · Jan Kiszka

Quoted 14 lines · Alexander Graf

Btw, it still tries to execute invalid code even with your patch. #if 0'ing out the memory region updates at least get the guest booting for me. Btw, to get it working you also need a patch for the interrupt controller (another breakage thanks to memory api).

hw/heathrow_pic.c +1 -1

index 51996ab..16f48d1 100644
@@ -126,7 +126,7 @@ static uint64_t pic_read(void *opaque, target_phys_addr_t addr,
 static const MemoryRegionOps heathrow_pic_ops = {
     .read = pic_read,
     .write = pic_write,
-    .endianness = DEVICE_NATIVE_ENDIAN,
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 

Quoted 6 lines

hw/heathrow_pic.c static uint64_t pic_read(void *opaque, target_phys_addr_t addr, · line 132

Quoted 2 lines

hw/heathrow_pic.c +0 -0

 static void heathrow_pic_set_irq(void *opaque, int num, int level)

With out without this fix, with or without active chain-4 optimization, I just get an empty yellow screen when firing up qemu-system-ppc (also when using the Debian ISO). Do I need to specify a specific machine type?

Quoted 5 lines

Ugh. No, you only need this patch:

  [PATCH] PPC: Fix via-cuda memory registration

which fixes another recently introduced regression :)

That works now - and allowed me to identify the bug after enhancing info mtree a bit:

(qemu) info mtree
memory
 addr 00000000 prio 0 size 7fffffffffffffff system addr 80880000 prio 1 size 80000 macio addr 808e0000 prio 0 size 20000 macio-nvram addr 808a0000 prio 0 size 1000 pmac-ide addr 80896000 prio 0 size 2000 cuda addr 80893000 prio 0 size 40 escc-bar addr 80888000 prio 0 size 1000 dbdma addr 80880000 prio 0 size 1000 heathrow-pic addr 80000000 prio 1 size 800000 vga.vram addr 800a0000 prio 1 size 20000 vga-lowmem
   ...

Here is the problem: Both the vram and the ISA range get mapped into system address space, but the former eclipses the latter as it shows up earlier in the list and has the same priority. This picture changes with the chain-4 alias which has prio 2, thus maps over the vram.

It looks to me like the ISA address space is either misplaced at 0x80000000 or is not supposed to be mapped at all on PPC. Comments?

Quoted 8 lines

Here is the problem: Both the vram and the ISA range get mapped into system address space, but the former eclipses the latter as it shows up earlier in the list and has the same priority. This picture changes with the chain-4 alias which has prio 2, thus maps over the vram.

It looks to me like the ISA address space is either misplaced at 0x80000000 or is not supposed to be mapped at all on PPC. Comments?

Since there is no PCI-ISA bridge, ISA address space shouldn't exist.

Quoted 6 lines · Blue Swirl

Quoted 6 lines

Here is the problem: Both the vram and the ISA range get mapped into system address space, but the former eclipses the latter as it shows up earlier in the list and has the same priority. This picture changes with the chain-4 alias which has prio 2, thus maps over the vram.

Quoted 4 lines

Quoted 2 lines

It looks to me like the ISA address space is either misplaced at 0x80000000 or is not supposed to be mapped at all on PPC. Comments?

Since there is no PCI-ISA bridge, ISA address space shouldn't exist.

Where does the vga device sit then?

Quoted 7 lines · Avi Kivity

Quoted 6 lines · Blue Swirl

Quoted 6 lines

Here is the problem: Both the vram and the ISA range get mapped into system address space, but the former eclipses the latter as it shows up earlier in the list and has the same priority. This picture changes with the chain-4 alias which has prio 2, thus maps over the vram.

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

It looks to me like the ISA address space is either misplaced at 0x80000000 or is not supposed to be mapped at all on PPC. Comments?

Since there is no PCI-ISA bridge, ISA address space shouldn't exist.

Where does the vga device sit then?

On the PCI bus? :)

Quoted 7 lines · Avi Kivity

Quoted 6 lines · Blue Swirl

Quoted 6 lines

Here is the problem: Both the vram and the ISA range get mapped into system address space, but the former eclipses the latter as it shows up earlier in the list and has the same priority. This picture changes with the chain-4 alias which has prio 2, thus maps over the vram.

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

It looks to me like the ISA address space is either misplaced at 0x80000000 or is not supposed to be mapped at all on PPC. Comments?

Since there is no PCI-ISA bridge, ISA address space shouldn't exist.

Where does the vga device sit then?

On the PCI bus? :)

Quoted 12 lines · Alexander Graf

Quoted 10 lines · Avi Kivity

Quoted 9 lines · Blue Swirl

Quoted 8 lines

Here is the problem: Both the vram and the ISA range get mapped into system address space, but the former eclipses the latter as it shows up earlier in the list and has the same priority. This picture changes with the chain-4 alias which has prio 2, thus maps over the vram.

It looks to me like the ISA address space is either misplaced at 0x80000000 or is not supposed to be mapped at all on PPC. Comments?

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

Since there is no PCI-ISA bridge, ISA address space shouldn't exist.

Where does the vga device sit then?

On the PCI bus? :)

I thought it was std vga, which is an ISA device.

Anyway PCI supports the vga region at 0xa0000-0xc0000. Where is it supposed to be mapped?

Quoted 3 lines

Anyway PCI supports the vga region at 0xa0000-0xc0000. Where is it supposed to be mapped?

...but not all PCI bridges make use of this feature / forward legacy requests.

Quoted 7 lines · Jan Kiszka

Quoted 3 lines

Anyway PCI supports the vga region at 0xa0000-0xc0000. Where is it supposed to be mapped?

...but not all PCI bridges make use of this feature / forward legacy requests.

Then this should be fixed in the bridge?

Quoted 5 lines · Avi Kivity

Quoted 4 lines · Jan Kiszka

Quoted 3 lines

Anyway PCI supports the vga region at 0xa0000-0xc0000. Where is it supposed to be mapped?

Quoted 5 lines

Quoted 3 lines

...but not all PCI bridges make use of this feature / forward legacy requests.

Then this should be fixed in the bridge?

Yes, it's a PPC bug.

Quoted 10 lines · Jan Kiszka

Quoted 9 lines · Avi Kivity

Quoted 7 lines · Jan Kiszka

Quoted 3 lines

Anyway PCI supports the vga region at 0xa0000-0xc0000. Where is it supposed to be mapped?

...but not all PCI bridges make use of this feature / forward legacy requests.

Quoted 3 lines

Quoted 1 line

Then this should be fixed in the bridge?

Yes, it's a PPC bug.

So how does the bridge not forward it then?

Quoted 10 lines · Jan Kiszka

Quoted 9 lines · Avi Kivity

Quoted 7 lines · Jan Kiszka

Quoted 3 lines

Anyway PCI supports the vga region at 0xa0000-0xc0000. Where is it supposed to be mapped?

...but not all PCI bridges make use of this feature / forward legacy requests.

Quoted 3 lines

Quoted 1 line

Then this should be fixed in the bridge?

Yes, it's a PPC bug.

So how does the bridge not forward it then?

Quoted 17 lines · Alexander Graf

Quoted 13 lines · Jan Kiszka

Quoted 10 lines · Avi Kivity

Quoted 7 lines · Jan Kiszka

Quoted 3 lines

 Anyway PCI supports the vga region at 0xa0000-0xc0000.  Where is it supposed to be mapped?

 ...but not all PCI bridges make use of this feature / forward legacy requests.

 Then this should be fixed in the bridge?

 Yes, it's a PPC bug.

Quoted 2 lines

So how does the bridge not forward it then?

I expect that currently vga adds the region to pci_address_space().  We need to create a pci_address_space_vga() function that returns a region for vga to use.  Then add or remove the region to pci_address_space(), within the bridge code, depending on whether the bridge forwards vga accesses or not.

(assuming I understood the problem correctly - not sure)

Quoted 18 lines · Avi Kivity

Quoted 17 lines · Alexander Graf

Quoted 13 lines · Jan Kiszka

Quoted 10 lines · Avi Kivity

Quoted 7 lines · Jan Kiszka

Quoted 3 lines

Anyway PCI supports the vga region at 0xa0000-0xc0000. Where is it supposed to be mapped?

...but not all PCI bridges make use of this feature / forward legacy requests.

Then this should be fixed in the bridge?

Yes, it's a PPC bug.

Quoted 7 lines

Quoted 2 lines

So how does the bridge not forward it then?

I expect that currently vga adds the region to pci_address_space(). We need to create a pci_address_space_vga() function that returns a region for vga to use. Then add or remove the region to pci_address_space(), within the bridge code, depending on whether the bridge forwards vga accesses or not.

Similar treatment should be also needed for VGA IO ports 0x3b0 etc.

Quoted 1 line

(assuming I understood the problem correctly - not sure)

I think you did.

Quoted 3 lines

Quoted 1 line

(assuming I understood the problem correctly - not sure)

I think you did.

Well I don't completely, so would anybody who feels reasonably savvy in messing with the new memory api like to step up and implement this? :)

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

(assuming I understood the problem correctly - not sure)

I think you did.

Well I don't completely, so would anybody who feels reasonably savvy in messing with the new memory api like to step up and implement this? :)

Can you explain what the memory map looks like from the hardware point of view?

Quoted 1 line

Can you explain what the memory map looks like from the hardware point of view?

If you can tell me where to find out :). I seriously have zero experience in VGA mapping - and it sounds as if Blue has a pretty good idea what's going on.

Quoted 4 lines

Quoted 2 lines

Can you explain what the memory map looks like from the hardware point of view?

If you can tell me where to find out :). I seriously have zero experience in VGA mapping - and it sounds as if Blue has a pretty good idea what's going on.

He's not interested in the VGA bits, but in the PPC board bits. How are addresses forwarded from the main system bus to the PCI host bridge, for instance?

Quoted 3 lines · Alexander Graf

Quoted 1 line

Can you explain what the memory map looks like from the hardware point of view?

If you can tell me where to find out :). I seriously have zero experience in VGA mapping - and it sounds as if Blue has a pretty good idea what's going on.

He's not interested in the VGA bits, but in the PPC board bits. How are addresses forwarded from the main system bus to the PCI host bridge, for instance?

Quoted 3 lines · Richard Henderson

Quoted 1 line · Alexander Graf

Quoted 1 line

Can you explain what the memory map looks like from the hardware

point of view?

Quoted 2 lines

Quoted 2 lines

If you can tell me where to find out :). I seriously have zero

experience in VGA mapping - and it sounds as if Blue has a pretty good idea what's going on.

Quoted 1 line

Quoted 3 lines

He's not interested in the VGA bits, but in the PPC board bits. How are addresses forwarded from the main system bus to the PCI host bridge, for instance?

Yeah, and what I'm trying to tell you is that I know about as much about the g3 beige as you do. However, Ben might now a bit more here. Let's ask him :).

Quoted 15 lines · Alexander Graf

Quoted 3 lines · Richard Henderson

Quoted 1 line · Alexander Graf

Quoted 1 line

Can you explain what the memory map looks like from the hardware

point of view?

Quoted 2 lines

Quoted 2 lines

If you can tell me where to find out :). I seriously have zero

experience in VGA mapping - and it sounds as if Blue has a pretty good idea what's going on.

Quoted 4 lines

He's not interested in the VGA bits, but in the PPC board bits. How are addresses forwarded from the main system bus to the PCI host bridge, for instance?

Quoted 3 lines

Yeah, and what I'm trying to tell you is that I know about as much about the g3 beige as you do. However, Ben might now a bit more here. Let's ask him :).

Can I have a bit of context please ? :-)

Quoted 15 lines · Alexander Graf

Quoted 3 lines · Richard Henderson

Quoted 1 line · Alexander Graf

Quoted 1 line

Can you explain what the memory map looks like from the hardware

point of view?

Quoted 2 lines

Quoted 2 lines

If you can tell me where to find out :). I seriously have zero

experience in VGA mapping - and it sounds as if Blue has a pretty good idea what's going on.

Quoted 4 lines

He's not interested in the VGA bits, but in the PPC board bits. How are addresses forwarded from the main system bus to the PCI host bridge, for instance?

Quoted 3 lines

Yeah, and what I'm trying to tell you is that I know about as much about the g3 beige as you do. However, Ben might now a bit more here. Let's ask him :).

Can I have a bit of context please ? :-)

Sure :). So the problem is that when emulating the G3 Beige machine in QEMU (default ppc32 target) we also add a PCI VGA adapter. Apparently, on x86 that PCI VGA adapter can map the special VGA regions to somewhere, namely 0xa0000. With the memory api overhaul, this also slipped into the PPC world where mapping 0xa0000 with VGA adapters is a pretty bad idea, as it's occupied by RAM.

Now the discussion was on which level that mapping would happen and which devices go through which buses which then would filter certain ranges from being mapped. Basically, which way does a memory request from the CPU go on a G3 Beige machine until it arrives the VGA adapter?

I hope that concludes the actual question. Avi, if I explained this wrong, please correct me.

From memory, the way it's configured in a G3 is to have a 1:1 mapping of

Quoted 7 lines

Sure :). So the problem is that when emulating the G3 Beige machine in QEMU (default ppc32 target) we also add a PCI VGA adapter. Apparently, on x86 that PCI VGA adapter can map the special VGA regions to somewhere, namely 0xa0000. With the memory api overhaul, this also slipped into the PPC world where mapping 0xa0000 with VGA adapters is a pretty bad idea, as it's occupied by RAM.

Quoted 8 lines

Now the discussion was on which level that mapping would happen and which devices go through which buses which then would filter certain ranges from being mapped. Basically, which way does a memory request from the CPU go on a G3 Beige machine until it arrives the VGA adapter?

I hope that concludes the actual question. Avi, if I explained this wrong, please correct me.

Ok so there's several things here.

First, the mapping from CPU addresses to PCI addresses. This depends on the host bridge chip. The MPC106, used in the Beige G3, itself supports different type of mappings.

From memory, the way it's configured in a G3 is to have a 1:1 mapping of
80000000 CPU to 80000000 PCI.

That means that with this basic mapping, you cannot generate memory accesses to low PCI addresses such as 0xa0000.

I don't remember (but it's possible) if it has another region which maps some other (high address) part of the address space down to 0 PCI. Typically that would be a smaller region which specifically allow access to the "ISA hole" that way.

Quoted 23 lines · Benjamin Herrenschmidt

Quoted 8 lines

 Sure :). So the problem is that when emulating the G3 Beige machine in QEMU (default ppc32 target) we also add a PCI VGA adapter. Apparently, on x86 that PCI VGA adapter can map the special VGA regions to somewhere, namely 0xa0000. With the memory api overhaul, this also slipped into the PPC world where mapping 0xa0000 with VGA adapters is a pretty bad idea, as it's occupied by RAM.

Quoted 8 lines

 Now the discussion was on which level that mapping would happen and which devices go through which buses which then would filter certain ranges from being mapped. Basically, which way does a memory request from the CPU go on a G3 Beige machine until it arrives the VGA adapter?

 I hope that concludes the actual question. Avi, if I explained this wrong, please correct me.

Ok so there's several things here.

First, the mapping from CPU addresses to PCI addresses. This depends on the host bridge chip. The MPC106, used in the Beige G3, itself supports different type of mappings.

Quoted 5 lines

 From memory, the way it's configured in a G3 is to have a 1:1 mapping of 80000000 CPU to 80000000 PCI.

That means that with this basic mapping, you cannot generate memory accesses to low PCI addresses such as 0xa0000.

Alex, what this means (I think is) that: pci_grackle_init() needs to create a container memory region and pass it to pc_register_bus() as the pci address space, and create and alias starting at 0x80000000 of the pci address space, and map that alias at address 0x80000000 of the system address space.

See pc_init1() creating pci_memory and passing it to i440fx_init(), which then maps some aliases into the system address space and also gives it to pci_bus_new().  It's essentially the same thing with different details.

Quoted 4 lines

I don't remember (but it's possible) if it has another region which maps some other (high address) part of the address space down to 0 PCI. Typically that would be a smaller region which specifically allow access to the "ISA hole" that way.

That would be done by mapping yet another alias.

--
error compiling committee.c: too many arguments to function

Quoted 36 lines · Avi Kivity

Quoted 23 lines · Benjamin Herrenschmidt

Quoted 8 lines

Sure :). So the problem is that when emulating the G3 Beige machine in QEMU (default ppc32 target) we also add a PCI VGA adapter. Apparently, on x86 that PCI VGA adapter can map the special VGA regions to somewhere, namely 0xa0000. With the memory api overhaul, this also slipped into the PPC world where mapping 0xa0000 with VGA adapters is a pretty bad idea, as it's occupied by RAM.

Quoted 8 lines

Now the discussion was on which level that mapping would happen and which devices go through which buses which then would filter certain ranges from being mapped. Basically, which way does a memory request from the CPU go on a G3 Beige machine until it arrives the VGA adapter?

I hope that concludes the actual question. Avi, if I explained this wrong, please correct me.

Ok so there's several things here.

First, the mapping from CPU addresses to PCI addresses. This depends on the host bridge chip. The MPC106, used in the Beige G3, itself supports different type of mappings.

Quoted 5 lines

From memory, the way it's configured in a G3 is to have a 1:1 mapping of
80000000 CPU to 80000000 PCI.

That means that with this basic mapping, you cannot generate memory accesses to low PCI addresses such as 0xa0000.

Alex, what this means (I think is) that: pci_grackle_init() needs to create a container memory region and pass it to pc_register_bus() as the pci address space, and create and alias starting at 0x80000000 of the pci address space, and map that alias at address 0x80000000 of the system address space.

Quoted 3 lines

See pc_init1() creating pci_memory and passing it to i440fx_init(), which then maps some aliases into the system address space and also gives it to pci_bus_new(). It's essentially the same thing with different details.

I think the attached patch (on top of ppc-next) should do it, but it doesn't. Only the top area of the screen is shown, the rest is black.

Quoted 36 lines · Avi Kivity

Quoted 23 lines · Benjamin Herrenschmidt

Quoted 8 lines

Sure :). So the problem is that when emulating the G3 Beige machine in QEMU (default ppc32 target) we also add a PCI VGA adapter. Apparently, on x86 that PCI VGA adapter can map the special VGA regions to somewhere, namely 0xa0000. With the memory api overhaul, this also slipped into the PPC world where mapping 0xa0000 with VGA adapters is a pretty bad idea, as it's occupied by RAM.

Quoted 8 lines

Now the discussion was on which level that mapping would happen and which devices go through which buses which then would filter certain ranges from being mapped. Basically, which way does a memory request from the CPU go on a G3 Beige machine until it arrives the VGA adapter?

I hope that concludes the actual question. Avi, if I explained this wrong, please correct me.

Ok so there's several things here.

First, the mapping from CPU addresses to PCI addresses. This depends on the host bridge chip. The MPC106, used in the Beige G3, itself supports different type of mappings.

Quoted 5 lines

From memory, the way it's configured in a G3 is to have a 1:1 mapping of
80000000 CPU to 80000000 PCI.

That means that with this basic mapping, you cannot generate memory accesses to low PCI addresses such as 0xa0000.

Alex, what this means (I think is) that: pci_grackle_init() needs to create a container memory region and pass it to pc_register_bus() as the pci address space, and create and alias starting at 0x80000000 of the pci address space, and map that alias at address 0x80000000 of the system address space.

Quoted 3 lines

See pc_init1() creating pci_memory and passing it to i440fx_init(), which then maps some aliases into the system address space and also gives it to pci_bus_new(). It's essentially the same thing with different details.

I think the attached patch (on top of ppc-next) should do it, but it doesn't. Only the top area of the screen is shown, the rest is black.

Quoted 37 lines · Blue Swirl

Quoted 36 lines · Avi Kivity

Quoted 23 lines · Benjamin Herrenschmidt

Quoted 8 lines

Sure :). So the problem is that when emulating the G3 Beige machine in QEMU (default ppc32 target) we also add a PCI VGA adapter. Apparently, on x86 that PCI VGA adapter can map the special VGA regions to somewhere, namely 0xa0000. With the memory api overhaul, this also slipped into the PPC world where mapping 0xa0000 with VGA adapters is a pretty bad idea, as it's occupied by RAM.

Quoted 8 lines

Now the discussion was on which level that mapping would happen and which devices go through which buses which then would filter certain ranges from being mapped. Basically, which way does a memory request from the CPU go on a G3 Beige machine until it arrives the VGA adapter?

I hope that concludes the actual question. Avi, if I explained this wrong, please correct me.

Ok so there's several things here.

First, the mapping from CPU addresses to PCI addresses. This depends on the host bridge chip. The MPC106, used in the Beige G3, itself supports different type of mappings.

Quoted 5 lines

From memory, the way it's configured in a G3 is to have a 1:1 mapping of
80000000 CPU to 80000000 PCI.

That means that with this basic mapping, you cannot generate memory accesses to low PCI addresses such as 0xa0000.

Alex, what this means (I think is) that: pci_grackle_init() needs to create a container memory region and pass it to pc_register_bus() as the pci address space, and create and alias starting at 0x80000000 of the pci address space, and map that alias at address 0x80000000 of the system address space.

Quoted 6 lines

Quoted 3 lines

See pc_init1() creating pci_memory and passing it to i440fx_init(), which then maps some aliases into the system address space and also gives it to pci_bus_new(). It's essentially the same thing with different details.

I think the attached patch (on top of ppc-next) should do it, but it doesn't. Only the top area of the screen is shown, the rest is black.

Without your patch:

(qemu) info mtree
memory
00000000-fffffffe : system
800a0000-800affff : vga.chain4

   80880000-808fffff : macio
     00060000-0007ffff : macio-nvram
     00020000-00020fff : pmac-ide
     00016000-00017fff : cuda
     00013000-0001303f : escc-bar
     00008000-00008fff : dbdma
     00000000-00000fff : heathrow-pic
   80800000-8080ffff : vga.rom
   80000000-807fffff : vga.vram
   800a0000-800bffff : vga-lowmem
   80013000-8001303f : escc
   fee00000-fee00fff : pci-data-idx
   fec00000-fec00fff : pci-conf-idx
   fe000000-fe1fffff : isa-mmio

With your patch:

(qemu) info mtree
memory
00000000-fffffffe : system
80013000-8001303f : escc
fee00000-fee00fff : pci-data-idx
fec00000-fec00fff : pci-conf-idx
80000000-fdffffff : pci-hole
fe000000-fe1fffff : isa-mmio

Since the VRAM is mapped to 0x80000000 which is now occupied by the hole and nothing behind it, nothing gets to write there?

Not sure - I still haven't understood how the memory api works.

Quoted 46 lines · Alexander Graf

Quoted 43 lines · Blue Swirl

Quoted 36 lines · Avi Kivity

Quoted 23 lines · Benjamin Herrenschmidt

Quoted 8 lines

Sure :). So the problem is that when emulating the G3 Beige machine in QEMU (default ppc32 target) we also add a PCI VGA adapter. Apparently, on x86 that PCI VGA adapter can map the special VGA regions to somewhere, namely 0xa0000. With the memory api overhaul, this also slipped into the PPC world where mapping 0xa0000 with VGA adapters is a pretty bad idea, as it's occupied by RAM.

Quoted 8 lines

Now the discussion was on which level that mapping would happen and which devices go through which buses which then would filter certain ranges from being mapped. Basically, which way does a memory request from the CPU go on a G3 Beige machine until it arrives the VGA adapter?

I hope that concludes the actual question. Avi, if I explained this wrong, please correct me.

Ok so there's several things here.

First, the mapping from CPU addresses to PCI addresses. This depends on the host bridge chip. The MPC106, used in the Beige G3, itself supports different type of mappings.

Quoted 5 lines

From memory, the way it's configured in a G3 is to have a 1:1 mapping of
80000000 CPU to 80000000 PCI.

That means that with this basic mapping, you cannot generate memory accesses to low PCI addresses such as 0xa0000.

Alex, what this means (I think is) that: pci_grackle_init() needs to create a container memory region and pass it to pc_register_bus() as the pci address space, and create and alias starting at 0x80000000 of the pci address space, and map that alias at address 0x80000000 of the system address space.

Quoted 3 lines

See pc_init1() creating pci_memory and passing it to i440fx_init(), which then maps some aliases into the system address space and also gives it to pci_bus_new(). It's essentially the same thing with different details.

I think the attached patch (on top of ppc-next) should do it, but it doesn't. Only the top area of the screen is shown, the rest is black.

Quoted 6 lines

Without your patch:

(qemu) info mtree
memory
00000000-fffffffe : system
800a0000-800affff : vga.chain4

This is here due to the isa_mem_base problem - I think we can get that part of the patch merged?

Quoted 10 lines

80880000-808fffff : macio

    00060000-0007ffff : macio-nvram
    00020000-00020fff : pmac-ide
    00016000-00017fff : cuda
    00013000-0001303f : escc-bar
    00008000-00008fff : dbdma
    00000000-00000fff : heathrow-pic

80800000-8080ffff : vga.rom
80000000-807fffff : vga.vram
800a0000-800bffff : vga-lowmem

Quoted 19 lines

80013000-8001303f : escc
fee00000-fee00fff : pci-data-idx
fec00000-fec00fff : pci-conf-idx
fe000000-fe1fffff : isa-mmio

With your patch:

(qemu) info mtree
memory
00000000-fffffffe : system
80013000-8001303f : escc
fee00000-fee00fff : pci-data-idx
fec00000-fec00fff : pci-conf-idx
80000000-fdffffff : pci-hole
fe000000-fe1fffff : isa-mmio

Quoted 1 line

Since the VRAM is mapped to 0x80000000 which is now occupied by the hole and nothing behind it, nothing gets to write there?

The memory printer doesn't follow aliases, so this is incomplete.

Quoted 3 lines

Not sure - I still haven't understood how the memory api works.

Thanks for reminding me to write up slides for tomorrow's code overview session. I'll start with a general explanation.

Quoted 11 lines

Quoted 11 lines

   80880000-808fffff : macio
     00060000-0007ffff : macio-nvram
     00020000-00020fff : pmac-ide
     00016000-00017fff : cuda
     00013000-0001303f : escc-bar
     00008000-00008fff : dbdma
     00000000-00000fff : heathrow-pic
   80800000-8080ffff : vga.rom
   80000000-807fffff : vga.vram
   800a0000-800bffff : vga-lowmem

Well what I don't understand is how this corresponds to the lowmem region here. If I simply #if 0 the chain4 code out, everything works as expected.

Quoted 5 lines

Quoted 3 lines

Not sure - I still haven't understood how the memory api works.

Thanks for reminding me to write up slides for tomorrow's code overview session. I'll start with a general explanation.

What code overview session?

Quoted 18 lines · Avi Kivity

Quoted 17 lines · Alexander Graf

Quoted 13 lines · Jan Kiszka

   On 2011-09-14 10:22, Avi Kivity wrote:

Quoted 10 lines · Jan Kiszka

Quoted 7 lines

Quoted 3 lines

Anyway PCI supports the vga region at 0xa0000-0xc0000. Where is it supposed to be mapped?

...but not all PCI bridges make use of this feature / forward legacy requests.

Then this should be fixed in the bridge?

Yes, it's a PPC bug.

Quoted 7 lines

Quoted 2 lines

So how does the bridge not forward it then?

I expect that currently vga adds the region to pci_address_space(). We need to create a pci_address_space_vga() function that returns a region for vga to use. Then add or remove the region to pci_address_space(), within the bridge code, depending on whether the bridge forwards vga accesses or not.

Similar treatment should be also needed for VGA IO ports 0x3b0 etc.

Quoted 1 line

(assuming I understood the problem correctly - not sure)

I think you did.

Quoted 36 lines · Blue Swirl

Quoted 23 lines · Avi Kivity

Quoted 19 lines · Alexander Graf

 On 14.09.2011, at 10:24, Jan Kiszka wrote:

 >    On 2011-09-14 10:22, Avi Kivity wrote:
 >>    On 09/14/2011 11:20 AM, Jan Kiszka wrote:
 >>>>
 >>>>    Anyway PCI supports the vga region at 0xa0000-0xc0000.  Where is it
 >>>>    supposed to be mapped?
 >>>
 >>>    ...but not all PCI bridges make use of this feature / forward legacy
 >>>    requests.
 >>>
 >>
 >>    Then this should be fixed in the bridge?
 >
 >    Yes, it's a PPC bug.

Quoted 2 lines

 So how does the bridge not forward it then?

Quoted 8 lines

 I expect that currently vga adds the region to pci_address_space().  We need
 to create a pci_address_space_vga() function that returns a region for vga
 to use.  Then add or remove the region to pci_address_space(), within the
 bridge code, depending on whether the bridge forwards vga accesses or not.

Similar treatment should be also needed for VGA IO ports 0x3b0 etc.

Quoted 3 lines

Quoted 1 line

 (assuming I understood the problem correctly - not sure)

I think you did.

Maybe, but the solution can't be right.  The bridge can't distinguish between a BAR mapped at 0xa0000 and the vga device claiming accesses to 0xa0000.  Is this what is happening?

The current pci bridge implementation (440fx) uses an alias to instantiate pci 0xa0000-0xc0000 at the same address in the host address space.  If you disable it, those addresses map back to RAM - but there is no distinction between a BAR at that address and a VGA card at that address.

--
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.

Quoted 41 lines · Avi Kivity

Quoted 39 lines · Blue Swirl

Quoted 23 lines · Avi Kivity

Quoted 12 lines · Alexander Graf

Quoted 4 lines · Jan Kiszka

     On 2011-09-14 10:22, Avi Kivity wrote:

Quoted 3 lines · Jan Kiszka

Quoted 2 lines

Quoted 2 lines

     Anyway PCI supports the vga region at 0xa0000-0xc0000.  Where

is it

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

supposed to be mapped?

...but not all PCI bridges make use of this feature / forward

legacy

Quoted 9 lines

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

requests.

Then this should be fixed in the bridge?

Yes, it's a PPC bug.

So how does the bridge not forward it then?

Quoted 8 lines

I expect that currently vga adds the region to pci_address_space(). We
need
to create a pci_address_space_vga() function that returns a region for
vga
to use. Then add or remove the region to pci_address_space(), within
the
bridge code, depending on whether the bridge forwards vga accesses or
not.

Similar treatment should be also needed for VGA IO ports 0x3b0 etc.

Quoted 1 line

(assuming I understood the problem correctly - not sure)

I think you did.

Quoted 3 lines

Maybe, but the solution can't be right. The bridge can't distinguish between a BAR mapped at 0xa0000 and the vga device claiming accesses to 0xa0000. Is this what is happening?

If VGA enable is set, the bridge will forward the accesses to VGA memory or ports to secondary interface. It doesn't care which device uses them. This is described in VGA support chapter in the PCI bridge spec.

Quoted 15 lines

Btw, it still tries to execute invalid code even with your patch. #if 0'ing out the memory region updates at least get the guest booting for me. Btw, to get it working you also need a patch for the interrupt controller (another breakage thanks to memory api).

hw/heathrow_pic.c +1 -1

index 51996ab..16f48d1 100644
@@ -126,7 +126,7 @@ static uint64_t pic_read(void *opaque,  
 target_phys_addr_t addr,
 static const MemoryRegionOps heathrow_pic_ops = {
    .read = pic_read,
    .write = pic_write,
-    .endianness = DEVICE_NATIVE_ENDIAN,
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 

Quoted 2 lines

static void heathrow_pic_set_irq(void *opaque, int num, int level)

With out without this fix, with or without active chain-4 optimization, I just get an empty yellow screen when firing up qemu-system-ppc (also when using the Debian ISO). Do I need to specify a specific machine type?

Quoted 14 lines · Jan Kiszka

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 <[email protected]>

CC Avi Kivity <[email protected]>

Signed-off-by Jan Kiszka <[email protected]>

[...]

Quoted 23 lines

hw/vga.c +22 -0

+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;

hw/vga.c static void vga_screen_dump(void *opaque, const char *filename); · line 186

Quoted 10 lines

hw/vga.c +10 -0

+            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

(quoted diff) +0 -13

-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

(quoted diff) +0 -10

-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 :).

Quoted 55 lines · Alexander Graf

Quoted 14 lines · Jan Kiszka

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 <[email protected]>

CC Avi Kivity <[email protected]>

Signed-off-by Jan Kiszka <[email protected]>

[...]

Quoted 23 lines

hw/vga.c +22 -0

+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;

hw/vga.c static void vga_screen_dump(void *opaque, const char *filename); · line 186

Quoted 10 lines

hw/vga.c +10 -0

+            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:

Quoted 1 line

(qemu) info mtree

:-)

Quoted 28 lines

memory
system addr 00000000 off 00000000 size 7fffffffffffffff

(quoted diff) +0 -13

-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

(quoted diff) +0 -10

-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

Quoted 4 lines

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 :).

I had similar problems with sun4u, fixed with f69539b14bdba7a5cd22e1f4bed439b476b17286. I think also here, PCI should be given a memory range at 0x80000000 and VGA should automatically use that like.

Quoted 5 lines

I had similar problems with sun4u, fixed with f69539b14bdba7a5cd22e1f4bed439b476b17286. I think also here, PCI should be given a memory range at 0x80000000 and VGA should automatically use that like.

Yeah, usually the ISA bus is behind an ISA-PCI bridge, so it should inherit the offset from its parent. Or do you mean something different?

Quoted 8 lines · Alexander Graf

Quoted 5 lines

I had similar problems with sun4u, fixed with f69539b14bdba7a5cd22e1f4bed439b476b17286. I think also here, PCI should be given a memory range at 0x80000000 and VGA should automatically use that like.

Yeah, usually the ISA bus is behind an ISA-PCI bridge, so it should inherit the offset from its parent. Or do you mean something different?

He means that isa_mem_base should go away; instead isa_address_space() should be a subregion at offset 0x80000000.

Which vga variant are you using?

Quoted 5 lines

Quoted 3 lines

Yeah, usually the ISA bus is behind an ISA-PCI bridge, so it should inherit the offset from its parent. Or do you mean something different?

He means that isa_mem_base should go away; instead isa_address_space() should be a subregion at offset 0x80000000.

So we are talking about the same thing. Logically speaking, ISA devices are behind the ISA-PCI bridge, so the parent would be the bridge, right?

Quoted 2 lines

Which vga variant are you using?

This is stdvga.

Rebased over latest qemu.git, addressing Avi's feedback and also fixing a regression of the vmware reset patch.

Patch 1 is still a candidate for stable.

PS: Just accidentally ran checkpatch against recent top of qemu.git as well - looks like not many maintainers use that tool themselves... (not really helpful when asking contributors to do this)

Cc Andrzej Zaborowski<[email protected]>

CC Andrzej Zaborowski<[email protected]>

CC Avi Kivity<[email protected]>

CC Gerd Hoffmann<[email protected]>

Jan Kiszka (6):
vmware-vga: Register reset service
vmware-vga: Disable verbose mode
vmware-vga: Remove dead DIRECT_VRAM mode
vmware-vga: Eliminate vga_dirty_log_restart
vga: Use linear mapping + dirty logging in chain 4 memory access mode
vga: Drop some unused fields

  hw/vga.c        |   57 +++++++++++--
  hw/vga_int.h    |    5 +-
  hw/vmware_vga.c |  242 +++++++++++++++----------------------------------------
  3 files changed, 118 insertions(+), 186 deletions(-)

Quoted 3 lines

PS: Just accidentally ran checkpatch against recent top of qemu.git as well - looks like not many maintainers use that tool themselves... (not really helpful when asking contributors to do this)

I'll bite, care to be more specific?