[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 12:19:10 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
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 <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.
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.
>