[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 04/11] hw/arm/aspeed: add a 'mmio-exec' property
Re: [Qemu-devel] [PATCH 04/11] hw/arm/aspeed: add a 'mmio-exec' property to boot from the FMC flash module
Mon, 24 Sep 2018 14:31:23 +0100
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.