On Tue, Sep 13, 2011 at 11:34 AM, Jan Kiszka <jan.kis...@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.
