Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode

[Jan Kiszka]

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

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux