Re: [Qemu-arm] [PATCH 04/11] hw/arm/aspeed: add a 'mmio-exec' property to boot from the FMC flash module

[Cédric Le Goater]

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.

Thanks,

C.