[Top][All Lists]

[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

From: Cédric Le Goater
Subject: Re: [Qemu-devel] [PATCH 04/11] hw/arm/aspeed: add a 'mmio-exec' property to boot from the FMC flash module
Date: Mon, 24 Sep 2018 15:59:26 +0200
User-agent: 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]