On 09/19/2018 08:51 AM, Cédric Le Goater wrote: > On 09/18/2018 08:44 PM, Peter Maydell wrote: >> On 31 August 2018 at 11:38, Cédric Le Goater <c...@kaod.org> wrote: >>> Now that MMIO execution is supported, introduce a 'mmio-exec' property >>> to boot directly from CE0 of the FMC controller using a memory region >>> alias. >> >> The name of this property seems to be a reference to QEMU's >> internals: is there some other name that would make more sense >> to a user who cares more about the guest and the emulated hardware? > > It is true that the user does not care about internals. > > "execute-from-flash" as you proposed below ? > >>> The overhead for the current firmware images using a custom U-Boot is >>> around 2 seconds, which is fine, but with a U-Boot from mainline, it >>> takes an extra 50 seconds or so to reach Linux. This might be related >>> to the fact that a device tree is used. >> >> Is this overhead just because we do a lot of execution from the >> mmio region and that's slower than execution from RAM ? > > That is what it seems but I haven't dug further the problem. The mainline > U-Boot also has a rewritten DRAM calibration. > > Using the logs is too painful so I would need to add some statistics on > what is being done. May be number of read/write ops on the flash model > that we could dump from the monitor, or some more low-level figures of > QEMU internals.
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 ? I am no expert of that area of QEMU but willing to experiment. Thanks, C. >>> MMIO execution is not activated by default because until boot time is >>> improved. >> >> Can the guest tell the difference? I'm wondering how much we >> might need to care about backward compatibility if in future >> we fix the performance problem, or if we can just switch the >> default to execute-from-flash without breaking guests. > > Yes that is a good a point. When performance is fixed, we should remove > the ROM region and the machine option. What I am proposing is a more of > a work around to analyze a problem than something we would keep in the > future. > > Thanks, > > C. >