Patchwork [v3,5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode

login
register
mail settings
Submitter Alexander Graf
Date Sept. 13, 2011, 8:40 a.m.
Message ID <6BA6355D-D77A-40F4-A8C4-61901A926E71@suse.de>
Download mbox | patch
Permalink /patch/114473/
State New
Headers show

Comments

Alexander Graf - Sept. 13, 2011, 8:40 a.m.
On 13.09.2011, at 10:14, Jan Kiszka wrote:

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

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



Alex
Jan Kiszka - Sept. 13, 2011, 9 a.m.
On 2011-09-13 10:40, Alexander Graf wrote:
> 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).
> 
> diff --git a/hw/heathrow_pic.c b/hw/heathrow_pic.c
> index 51996ab..16f48d1 100644
> --- a/hw/heathrow_pic.c
> +++ b/hw/heathrow_pic.c
> @@ -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,
>  };
>  
>  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?

Jan
Alexander Graf - Sept. 13, 2011, 9:42 a.m.
On 13.09.2011, at 11:00, Jan Kiszka wrote:

> On 2011-09-13 10:40, Alexander Graf wrote:
>> 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).
>> 
>> diff --git a/hw/heathrow_pic.c b/hw/heathrow_pic.c
>> index 51996ab..16f48d1 100644
>> --- a/hw/heathrow_pic.c
>> +++ b/hw/heathrow_pic.c
>> @@ -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,
>> };
>> 
>> 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 :)


Alex
Andreas Färber - Sept. 13, 2011, 9:43 a.m.
Am 13.09.2011 um 11:00 schrieb Jan Kiszka:

> On 2011-09-13 10:40, Alexander Graf wrote:
>> 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).
>>
>> diff --git a/hw/heathrow_pic.c b/hw/heathrow_pic.c
>> index 51996ab..16f48d1 100644
>> --- a/hw/heathrow_pic.c
>> +++ b/hw/heathrow_pic.c
>> @@ -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,
>> };
>>
>> 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?

No. Did you try with Alex' via-cuda patch? That's the only one I have  
on my branch for Linux host.

Andreas
Jan Kiszka - Sept. 13, 2011, 11:34 a.m.
On 2011-09-13 11:42, Alexander Graf wrote:
> 
> On 13.09.2011, at 11:00, Jan Kiszka wrote:
> 
>> On 2011-09-13 10:40, Alexander Graf wrote:
>>> 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).
>>>
>>> diff --git a/hw/heathrow_pic.c b/hw/heathrow_pic.c
>>> index 51996ab..16f48d1 100644
>>> --- a/hw/heathrow_pic.c
>>> +++ b/hw/heathrow_pic.c
>>> @@ -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,
>>> };
>>>
>>> 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 :)

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?

Jan
Blue Swirl - Sept. 13, 2011, 7:39 p.m.
On Tue, Sep 13, 2011 at 11:34 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2011-09-13 11:42, Alexander Graf wrote:
>>
>> On 13.09.2011, at 11:00, Jan Kiszka wrote:
>>
>>> On 2011-09-13 10:40, Alexander Graf wrote:
>>>> 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).
>>>>
>>>> diff --git a/hw/heathrow_pic.c b/hw/heathrow_pic.c
>>>> index 51996ab..16f48d1 100644
>>>> --- a/hw/heathrow_pic.c
>>>> +++ b/hw/heathrow_pic.c
>>>> @@ -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,
>>>> };
>>>>
>>>> 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 :)
>
> 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?

Since there is no PCI-ISA bridge, ISA address space shouldn't exist.
Avi Kivity - Sept. 14, 2011, 7:11 a.m.
On 09/13/2011 10:39 PM, Blue Swirl wrote:
> >
> >  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.

Where does the vga device sit then?
Alexander Graf - Sept. 14, 2011, 7:42 a.m.
On 14.09.2011, at 09:11, Avi Kivity wrote:

> On 09/13/2011 10:39 PM, Blue Swirl wrote:
>> >
>> >  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.
> 
> Where does the vga device sit then?

On the PCI bus? :)


Alex
Jan Kiszka - Sept. 14, 2011, 8:02 a.m.
On 2011-09-14 09:42, Alexander Graf wrote:
> 
> On 14.09.2011, at 09:11, Avi Kivity wrote:
> 
>> On 09/13/2011 10:39 PM, Blue Swirl wrote:
>>>>
>>>>  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.
>>
>> Where does the vga device sit then?
> 
> On the PCI bus? :)

Then make sure that the container for ISA resources is a dummy region -
or even NULL so that VGA will know that it's supposed to skip ISA
registrations.

Jan
Avi Kivity - Sept. 14, 2011, 8:17 a.m.
On 09/14/2011 10:42 AM, Alexander Graf wrote:
> On 14.09.2011, at 09:11, Avi Kivity wrote:
>
> >  On 09/13/2011 10:39 PM, Blue Swirl wrote:
> >>  >
> >>  >   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.
> >
> >  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?
Jan Kiszka - Sept. 14, 2011, 8:20 a.m.
On 2011-09-14 10:17, Avi Kivity wrote:
> On 09/14/2011 10:42 AM, Alexander Graf wrote:
>> On 14.09.2011, at 09:11, Avi Kivity wrote:
>>
>>>  On 09/13/2011 10:39 PM, Blue Swirl wrote:
>>>>  >
>>>>  >   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.
>>>
>>>  Where does the vga device sit then?
>>
>> On the PCI bus? :)
>>
> 
> I thought it was std vga, which is an ISA device.

There are both types (ISA-only and PCI).

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

Jan
Avi Kivity - Sept. 14, 2011, 8:22 a.m.
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?
Jan Kiszka - Sept. 14, 2011, 8:24 a.m.
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.

Jan
Alexander Graf - Sept. 14, 2011, 8:27 a.m.
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.

So how does the bridge not forward it then?


Alex
Jan Kiszka - Sept. 14, 2011, 8:33 a.m.
On 2011-09-14 10:27, Alexander Graf wrote:
> 
> 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.
> 
> So how does the bridge not forward it then?

On real HW, by keeping the "VGA Enable" bit off. Or just not issuing
requests to the a0000..bffff range.

Under QEMU, I would simply provide the VGA model a memory region for
legacy stuff that remains unregistered.

Jan
Avi Kivity - Sept. 14, 2011, 8:35 a.m.
On 09/14/2011 11:27 AM, Alexander Graf wrote:
> 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.
>
> 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)
Blue Swirl - Sept. 14, 2011, 8:06 p.m.
On Wed, Sep 14, 2011 at 8:35 AM, Avi Kivity <avi@redhat.com> wrote:
> On 09/14/2011 11:27 AM, Alexander Graf wrote:
>>
>> 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.
>>
>> 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.

> (assuming I understood the problem correctly - not sure)

I think you did.
Alexander Graf - Sept. 14, 2011, 8:14 p.m.
On 14.09.2011, at 22:06, Blue Swirl wrote:

> On Wed, Sep 14, 2011 at 8:35 AM, Avi Kivity <avi@redhat.com> wrote:
>> On 09/14/2011 11:27 AM, Alexander Graf wrote:
>>> 
>>> 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.
>>> 
>>> 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.
> 
>> (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? :)


Alex
Avi Kivity - Sept. 14, 2011, 8:15 p.m.
On 09/14/2011 11:06 PM, Blue Swirl wrote:
> On Wed, Sep 14, 2011 at 8:35 AM, Avi Kivity<avi@redhat.com>  wrote:
> >  On 09/14/2011 11:27 AM, Alexander Graf wrote:
> >>
> >>  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.
> >>
> >>  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.
>
> >  (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.
Avi Kivity - Sept. 14, 2011, 8:16 p.m.
On 09/14/2011 11:14 PM, Alexander Graf wrote:
> >>  (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?
Blue Swirl - Sept. 14, 2011, 8:25 p.m.
On Wed, Sep 14, 2011 at 8:15 PM, Avi Kivity <avi@redhat.com> wrote:
> On 09/14/2011 11:06 PM, Blue Swirl wrote:
>>
>> On Wed, Sep 14, 2011 at 8:35 AM, Avi Kivity<avi@redhat.com>  wrote:
>> >  On 09/14/2011 11:27 AM, Alexander Graf wrote:
>> >>
>> >>  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.
>> >>
>> >>  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.
>>
>> >  (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?

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.

> 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.
>
>
Alexander Graf - Sept. 14, 2011, 8:35 p.m.
Am 14.09.2011 um 22:16 schrieb Avi Kivity <avi@redhat.com>:

> On 09/14/2011 11:14 PM, Alexander Graf wrote:
>> >>  (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?

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.

Alex

>
Richard Henderson - Sept. 14, 2011, 8:42 p.m.
On 09/14/2011 01:35 PM, Alexander Graf wrote:

>> 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?


r~
Andreas Färber - Sept. 14, 2011, 9:27 p.m.
Am 14.09.2011 um 22:42 schrieb Richard Henderson:

> On 09/14/2011 01:35 PM, Alexander Graf wrote:
>
>>> 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?

Does this help?

http://tibit.org/ppc/imac-333.html

The historical dev trees at http://penguinppc.org/historical/dev-trees-html/trees-index.html 
  seem to have disappeared, this iMac seems closest: The ATI VGA card  
sits directly on /pci.

Later models of PowerMac G3 had AGP graphics, the final PowerMac G5  
models had PCIe graphics.
Note that ATI graphic cards were sold as special Mac Edition, so I  
wouldn't completely rule out deviations from PC standards...

Andreas
Alexander Graf - Sept. 14, 2011, 9:41 p.m.
On 14.09.2011, at 22:42, Richard Henderson wrote:

> On 09/14/2011 01:35 PM, Alexander Graf wrote:
> 
>>> 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?

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


Alex
Benjamin Herrenschmidt - Sept. 15, 2011, 1:24 a.m.
On Wed, 2011-09-14 at 23:41 +0200, Alexander Graf wrote:
> On 14.09.2011, at 22:42, Richard Henderson wrote:
> 
> > On 09/14/2011 01:35 PM, Alexander Graf wrote:
> > 
> >>> 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?
> 
> 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 ? :-)

Cheers,
Ben.
Avi Kivity - Sept. 15, 2011, 7:30 a.m.
On 09/14/2011 11:25 PM, Blue Swirl wrote:
> On Wed, Sep 14, 2011 at 8:15 PM, Avi Kivity<avi@redhat.com>  wrote:
> >  On 09/14/2011 11:06 PM, Blue Swirl wrote:
> >>
> >>  On Wed, Sep 14, 2011 at 8:35 AM, Avi Kivity<avi@redhat.com>    wrote:
> >>  >    On 09/14/2011 11:27 AM, Alexander Graf wrote:
> >>  >>
> >>  >>    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.
> >>  >>
> >>  >>    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.
> >>
> >>  >    (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?
>
> 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.

That doesn't match the original description, where it appeared that the 
vga window collided with a BAR.
Avi Kivity - Sept. 15, 2011, 7:32 a.m.
On 09/15/2011 04:24 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2011-09-14 at 23:41 +0200, Alexander Graf wrote:
> >  On 14.09.2011, at 22:42, Richard Henderson wrote:
> >
> >  >  On 09/14/2011 01:35 PM, Alexander Graf wrote:
> >  >
> >  >>>  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?
> >
> >  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 ? :-)

What does the memory map regarding a pci vga card looks like?  Right now 
it looks like some BAR has collided with the legacy vga range at 0xa0000 
(maped to 0x8000a0000) or  such.  What is supposed to be where?
Alexander Graf - Sept. 15, 2011, 7:35 a.m.
On 15.09.2011, at 03:24, Benjamin Herrenschmidt wrote:

> On Wed, 2011-09-14 at 23:41 +0200, Alexander Graf wrote:
>> On 14.09.2011, at 22:42, Richard Henderson wrote:
>> 
>>> On 09/14/2011 01:35 PM, Alexander Graf wrote:
>>> 
>>>>> 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?
>> 
>> 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.


Alex
Benjamin Herrenschmidt - Sept. 15, 2011, 10:01 a.m.
> 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.

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.

There is code in pci_process_bridge_OF_ranges() that  will detect such
an ISA hole, and while it cannot add it to the normal resource
management, it is remembered, so we -could- use it from the VGA code if
we wanted to (we don't today).

The problem is that most bridges used on Macs, typically the Apple ones
simply don't provide such a hole. In fact, most bridges used by IBM
aren't configured for that either.

Now back to your VGA adapter. The legacy VGA stuff does something called
"hard decoding", which means it decodes those legacy addresses, usually
without a BAR, but using a fixed address decoding. This is old ISA crap
emulated on top of PCI, exist only thanks to a "hack" in the PCI spec,
in order to be backward compatible with DOS and shit like that.

Ideally, you should provide a BAR to allow remapping that stuff
elsewhere and a setting to enable/disable the hard-decoding. That way,
on power, the firmware could just whack that setting and turn your VGA
device into something that behaves properly like a normal PCI device.

Macs or pSeries never really used the legacy crap. We always had drivers
that configured the cards into "native" mode, which means no hard
decoding (some old cards still hard decoded some IO ports but that went
away on anything modern), and just using proper MMIO register and linear
framebuffer from the driver. That does mean we never used text mode
though. It would be possible to still allow text mode by having a BAR in
the emulated card that can be used to move the VGA legacy crap around
tho if we really wanted to.

BTW. I haven't looked at the code, but I've been told that for some of
the splice stuff or other higher level additions, you have implemented
special IO ports in the card. This is totally ass backward. IOs are old
bad junk and must die. MMIO is semi-acceptable, commands in virtio would
be better (and perform better), but not IO ports, please ..... 

Cheers,
Ben.
Avi Kivity - Sept. 15, 2011, 11:31 a.m.
On 09/15/2011 01:01 PM, Benjamin Herrenschmidt wrote:
> >  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.
>
> 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.

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.

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

Patch

diff --git a/hw/heathrow_pic.c b/hw/heathrow_pic.c
index 51996ab..16f48d1 100644
--- a/hw/heathrow_pic.c
+++ b/hw/heathrow_pic.c
@@ -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,
 };
 
 static void heathrow_pic_set_irq(void *opaque, int num, int level)