[Top][All Lists]

[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

From: Cédric Le Goater
Subject: Re: [Qemu-arm] [PATCH 04/11] hw/arm/aspeed: add a 'mmio-exec' property to boot from the FMC flash module
Date: Wed, 19 Sep 2018 08:51:28 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 09/18/2018 08:44 PM, Peter Maydell wrote:
> On 31 August 2018 at 11:38, Cédric Le Goater <address@hidden> 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. 

>> 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 



reply via email to

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