[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [PATCH 04/11] hw/arm/aspeed: add a 'mmio-exec' property t
Cédric Le Goater
Re: [Qemu-arm] [PATCH 04/11] hw/arm/aspeed: add a 'mmio-exec' property to boot from the FMC flash module
Mon, 24 Sep 2018 15:59:26 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
On 09/24/2018 03:31 PM, Peter Maydell wrote:
> On 24 September 2018 at 14:28, Cédric Le Goater <address@hidden> wrote:
>> On 09/24/2018 01:41 PM, Peter Maydell wrote:
>>> On 19 September 2018 at 11:19, Cédric Le Goater <address@hidden> wrote:
>>>> These are the number of read operations done on the flash memory region :
>>>> 922478 ~ 3.5 MBytes OpenBMC U-Boot
>>>> 20569977 ~ 80 MBytes Mainline U-Boot
>>>> So we are trashing the TBs I would say. Is there a way to increase the
>>>> TB size ? or some other TB parameter ? Is that directly linked to the
>>>> instruction cache size ?
>>> Well, execution direct from MMIO means we read each instruction
>>> as we execute it -- there's no caching of TBs. (We generate a
>>> temporary TB with a single insn and throw it away after executing
>>> from it.) This is because we can't be sure that we would get the
>>> same data value the next time we read from the address.
>> In our case, we should have the same data. So may be I can introduce
>> a read-only region with a cache to speed up the accesses. A bit like
>> this was done with the previous mmio inteface.
> Yes, this is in theory possible, but we dropped the old
> mmio-exec interface because it had some nasty race conditions:
> the problem is being able to be sure you've properly dropped
> the cached TBs when the device contents change.
> Which flash device is this? For pflash typically the 'romd mode'
> stuff suffices to allow execution as-if-from-ram most of the time.
It's a SPI slave flash device attached to the Aspeed SMC controller.
It works very well with in a 'romd mode'. I am just stressing a bit
more the model with MMIO execution but it's not something we really
need. So we can just drop this patch in the v2 patchset "aspeed: misc
fixes and enhancements (SMC)" in which I fixed a few other things.