qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>,
	qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: Leif Lindholm <quic_llindhol@quicinc.com>,
	Radoslaw Biernacki <rad@semihalf.com>
Subject: Re: [PATCH 0/3] target/arm: Make the counter frequency default 1GHz for new CPUs, machines
Date: Mon, 22 Apr 2024 15:38:50 +0200	[thread overview]
Message-ID: <c84bfac7-5fb5-4fca-90a3-93adb40bcf3c@linaro.org> (raw)
In-Reply-To: <CAFEAcA91ZULEjEgTotevp-epgH_azcwrSi9PVnnOSk8gq5j22g@mail.gmail.com>

W dniu 22.04.2024 o 14:56, Peter Maydell pisze:
> On Fri, 19 Apr 2024 at 19:46, Peter Maydell <peter.maydell@linaro.org> wrote:

>> The upshot is that the only CPU type that changes is 'max'; but any
>> new type we add in future (whether v8.6 or not) will also get the new
>> 1GHz default (assuming we spot in code review any attempts to set
>> the ARM_FEATURE_BACKCOMPAT_CNTFRQ flag on new CPU types as a result
>> of cut-n-paste from an older CPU initfn ;-)).
>>
>> It remains the case that the machine model can override the default
>> value via the 'cntfrq' QOM property (regardless of the CPU type).
> 
> This patchset turns out to break the sbsa-ref board: the
> Aarch64SbsarefMachine.test_sbsaref_alpine_linux_max_pauth_impdef
> avocado test both (a) takes rather longer to boot and (b) when
> running thinks that time is advancing very fast.
> 
> I suspect this may be because the firmware hard-codes the
> generic timer clock frequency it is expecting. I've cc'd the
> sbsa-ref maintainers: is that correct?
> 
> If so, we can deal with it by making the sbsa-ref board set the
> cntfrq QOM property on its CPUs to force them to the old
> frequency. However this will produce a technically-out-of-spec
> CPU when used with a v8.6-compliant CPU type, so probably we
> should do something to be able to tell the firmware the clock
> frequency (if it doesn't want to just read CNTFRQ_EL0 itself).

 From what I see in EDK2 code we read CNTFREQ_EL0:

GetPlatformTimerFreq() checks for PcdArmArchTimerFreqInHz variable which
sbsa-ref has set to 0. So it calls ArmGenericTimerGetTimerFreq() ->
ArmReadCntFrq() -> "mrs x0, cntfrq_el0"

I added debug output to firmware and it shows me:

HRW: GetPlatformTimerFreq TimerFreq = 62500000

Local tree:
ed0604e99c (HEAD -> test-counter) target/arm: Default to 1GHz cntfrq for 'max' and new CPUs
c0a8c341f5 target/arm: Refactor default generic timer frequency handling
592c01312b hw: Add compat machines for 9.1
62dbe54c24 (tag: v9.0.0-rc4, origin/master, origin/HEAD) Update version for v9.0.0-rc4 release
a12214d1c4 (origin/staging) usb-storage: Fix BlockConf defaults

sbsa-ref with "-cpu max" used. All cpu cores give me same value.


  reply	other threads:[~2024-04-22 13:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-19 18:46 [PATCH 0/3] target/arm: Make the counter frequency default 1GHz for new CPUs, machines Peter Maydell
2024-04-19 18:46 ` [PATCH 1/3] hw: Add compat machines for 9.1 Peter Maydell
2024-04-19 18:46 ` [PATCH 2/3] target/arm: Refactor default generic timer frequency handling Peter Maydell
2024-04-20 16:58   ` Richard Henderson
2024-04-23 12:12   ` Philippe Mathieu-Daudé
2024-04-19 18:46 ` [PATCH 3/3] target/arm: Default to 1GHz cntfrq for 'max' and new CPUs Peter Maydell
2024-04-20 17:04   ` Richard Henderson
2024-04-23 20:47   ` Philippe Mathieu-Daudé
2024-04-22 12:56 ` [PATCH 0/3] target/arm: Make the counter frequency default 1GHz for new CPUs, machines Peter Maydell
2024-04-22 13:38   ` Marcin Juszkiewicz [this message]
2024-04-22 14:18     ` Peter Maydell
2024-04-22 15:37       ` Marcin Juszkiewicz
2024-04-23  7:26         ` Marcin Juszkiewicz
2024-04-22 15:57       ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c84bfac7-5fb5-4fca-90a3-93adb40bcf3c@linaro.org \
    --to=marcin.juszkiewicz@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quic_llindhol@quicinc.com \
    --cc=rad@semihalf.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).