[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [PATCH v2 1/6] aspeed: add support for the witherspoon-bm
From: |
Cédric Le Goater |
Subject: |
Re: [Qemu-arm] [PATCH v2 1/6] aspeed: add support for the witherspoon-bmc board |
Date: |
Tue, 10 Oct 2017 15:21:02 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
On 10/10/2017 11:54 AM, Peter Maydell wrote:
> On 10 October 2017 at 10:19, Cédric Le Goater <address@hidden> wrote:
>> On 10/06/2017 05:10 PM, Peter Maydell wrote:
>>>> + mc->ignore_memory_transaction_failures = true;
>>>
>>> Please don't set this flag for new board models, it is only
>>> for our legacy existing ones. Instead implement any devices
>>> that you need for guest code to boot (stub them out with
>>> create_unimplemented_device() if you like).
>>
>> I have dug into this a little more and it seems that it is
>> required for the Aspeed bootloader (a modified u-boot) which
>> uses static variables in early init phases. So legacy firmwares
>> won't work in QEMU but will on real HW.
>>
>> It's fine with me but what is the goal of the approach ? Force
>> SoC providers into fixing their FW when they use QEMU ?
>
> The goal is to model hardware correctly. Hardware gives
> aborts if you touch a physical address with no device there,
> and so QEMU's model should do the same. If you have guest
> code that touches a physical address and blows up because
> of an abort (but doesn't when run on h/w) then either:
> * it is trying to probe a device that exists in real h/w:
> you need to provide a stub implementation in QEMU
> * the SoC's bus fabric really doesn't pass aborts back
> to the CPU; I think this is unlikely, but you can model
> it at the SoC level with a suitable default memory region
well, that is case it seems.
Anyhow, I found the required fixes in u-boot, so I will go with
ignore_memory_transaction_failures=false with this new machine.
Thanks,
C.
> The purpose of the flag is purely for existing board models,
> where it is impossible to enable the correct (abort)
> behaviour without possibly breaking guest code images that
> work for people using released QEMU code. On a new board
> model we don't have that problem and we can get it right
> from the start. If we don't get it right from the start
> then we will never have a chance to fix it in future.
>
> Our mismodelling of this (not turning accesses to invalid
> addresses into CPU aborts) meant that in the past it was
> possible to be lazy when implementing a board model and
> just not model half the hardware at all. Now it isn't,
> but I don't think that adding a set of calls to
> create_unimplemented_device() is a significant imposition.
>
> thanks
> -- PMM
>