All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@csgraf.de>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: "Eduardo Habkost" <eduardo@habkost.net>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Alistair Francis" <alistair@alistair23.me>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Beniamino Galvani" <b.galvani@gmail.com>,
	"Andre Przywara" <andre.przywara@arm.com>,
	"Tyrone Ting" <kfting@nuvoton.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Jean-Christophe Dubois" <jcd@tribudubois.net>,
	"Yanan Wang" <wangyanan55@huawei.com>,
	"Andrew Jeffery" <andrew@aj.id.au>,
	"Niek Linnenbank" <nieklinnenbank@gmail.com>,
	qemu-arm <qemu-arm@nongnu.org>,
	"Igor Mitsyanko" <i.mitsyanko@gmail.com>,
	"Cédric Le Goater" <clg@kaod.org>,
	"Havard Skinnemoen" <hskinnemoen@google.com>,
	"Andrey Smirnov" <andrew.smirnov@gmail.com>,
	"Michal Simek" <michal.simek@xilinx.com>,
	"Joel Stanley" <joel@jms.id.au>
Subject: Re: [PATCH 06/16] hw/arm/xlnx-zcu102: Don't enable PSCI conduit when booting guest in EL3
Date: Mon, 7 Feb 2022 17:24:35 +0100	[thread overview]
Message-ID: <0da64aa5-97b3-540b-0fc9-cb9bf670d487@csgraf.de> (raw)
In-Reply-To: <cc73e2f0-97e1-f9c5-1a89-45ff2b0a2aeb@amsat.org>


On 07.02.22 17:06, Philippe Mathieu-Daudé wrote:
> On 7/2/22 16:59, Alexander Graf wrote:
>>
>> On 07.02.22 16:52, Edgar E. Iglesias wrote:
>
>>> Both Versal and ZynqMP require MicroBlaze firmware to run the 
>>> reference implementations of Trusted Firmware. We never supported 
>>> this in upstream QEMU but we do support it with our fork (by running 
>>> multiple QEMU instances co-simulating).
>>>
>>> Having said that, we do have tons of EL3 test-cases that we use to 
>>> validate QEMU that run with EL3 enabled in upstream.
>>>
>>> So there's two user flows:
>>> 1. Direct boots using QEMUs builtin PSCI (Most users use this to run 
>>> Linux, Xen, U-boot, etc)
>>> 2. Firmware boot at EL3 without QEMUs builtin PSCI (Mostly used by 
>>> test-code)
>>>
>>> Number #2 is the one affected here and that by accident used to have 
>>> the builtin PSCI support enabled but now requires more power control 
>>> modelling to keep working.
>>> Unless I'm missing something, the -kernel boots will continue to use 
>>> the builtin PSCI implementation.
>>
>>
>> So nobody is using upstream QEMU to validate and prototype 
>> ATF/EL1s/EL0s code? That's a shame :). I suppose there is little 
>> value without the bitstream emulation and R cluster. Do you have 
>> plans to bring multi process emulation upstream some day to enable 
>> these there?
>
> The R cluster is already in mainstream, isn't it?


In that case, wouldn't it make sense to build an emulation model of the 
PMU behavior so that normal ATF works out of the box?


Thanks,

Alex



  reply	other threads:[~2022-02-07 17:10 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-27 15:46 [PATCH 00/16] arm: Fix handling of unrecognized functions in PSCI emulation Peter Maydell
2022-01-27 15:46 ` [PATCH 01/16] target/arm: make psci-conduit settable after realize Peter Maydell
2022-01-30 21:34   ` Richard Henderson
2022-01-27 15:46 ` [PATCH 02/16] cpu.c: Make start-powered-off " Peter Maydell
2022-01-30 21:46   ` Richard Henderson
2022-01-27 15:46 ` [PATCH 03/16] hw/arm/boot: Support setting psci-conduit based on guest EL Peter Maydell
2022-01-30 22:15   ` Richard Henderson
2022-01-27 15:46 ` [PATCH 04/16] hw/arm: imx: Don't enable PSCI conduit when booting guest in EL3 Peter Maydell
2022-01-31  6:43   ` Richard Henderson
2022-01-27 15:46 ` [PATCH 05/16] hw/arm: allwinner: " Peter Maydell
2022-01-30 22:35   ` Niek Linnenbank
2022-01-31 10:52     ` Andre Przywara
2022-02-02 21:11       ` Samuel Holland
2022-01-27 15:46 ` [PATCH 06/16] hw/arm/xlnx-zcu102: " Peter Maydell
2022-01-31  6:49   ` Richard Henderson
2022-02-07 14:21   ` Alexander Graf
2022-02-07 15:22     ` Peter Maydell
2022-02-07 15:33       ` Alexander Graf
2022-02-07 15:52         ` Edgar E. Iglesias
2022-02-07 15:59           ` Alexander Graf
2022-02-07 16:06             ` Philippe Mathieu-Daudé via
2022-02-07 16:24               ` Alexander Graf [this message]
2022-02-07 18:13                 ` Edgar E. Iglesias
2022-02-07 18:59                   ` Philippe Mathieu-Daudé via
2022-02-07 23:20                     ` Alexander Graf
2022-01-27 15:46 ` [PATCH 07/16] hw/arm/versal: Let boot.c handle PSCI enablement Peter Maydell
2022-01-31  6:50   ` Richard Henderson
2022-02-07 14:26   ` Alexander Graf
2022-01-27 15:46 ` [PATCH 08/16] hw/arm/virt: " Peter Maydell
2022-01-31  6:52   ` Richard Henderson
2022-01-27 15:46 ` [PATCH 09/16] hw/arm: highbank: For EL3 guests, don't enable PSCI, start all cores Peter Maydell
2022-01-31  6:55   ` Richard Henderson
2022-01-27 15:46 ` [PATCH 10/16] Revert "Revert "arm: tcg: Adhere to SMCCC 1.3 section 5.2"" Peter Maydell
2022-01-31  6:57   ` Richard Henderson
2022-02-07 14:29   ` Alexander Graf
2022-01-27 15:46 ` [PATCH 11/16] hw/arm/highbank: Drop use of secure_board_setup Peter Maydell
2022-01-31  8:03   ` Richard Henderson
2022-01-27 15:46 ` [PATCH 12/16] hw/arm/boot: Prevent setting both psci_conduit and secure_board_setup Peter Maydell
2022-01-31  8:04   ` Richard Henderson
2022-01-27 15:46 ` [PATCH 13/16] hw/arm/boot: Don't write secondary boot stub if using PSCI Peter Maydell
2022-01-31  8:06   ` Richard Henderson
2022-01-27 15:46 ` [PATCH 14/16] hw/arm/highbank: Drop unused secondary boot stub code Peter Maydell
2022-01-31  8:08   ` Richard Henderson
2022-01-27 15:46 ` [PATCH 15/16] hw/arm/boot: Drop nb_cpus field from arm_boot_info Peter Maydell
2022-01-31  8:09   ` Richard Henderson
2022-01-27 15:46 ` [PATCH 16/16] hw/arm/boot: Drop existing dtb /psci node rather than retaining it Peter Maydell
2022-01-31  8:21   ` Richard Henderson
2022-01-30 14:03 ` [PATCH 00/16] arm: Fix handling of unrecognized functions in PSCI emulation Edgar E. Iglesias
2022-02-01  8:32 ` Cédric Le Goater
2022-02-07 11:19 ` 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=0da64aa5-97b3-540b-0fc9-cb9bf670d487@csgraf.de \
    --to=agraf@csgraf.de \
    --cc=alistair@alistair23.me \
    --cc=andre.przywara@arm.com \
    --cc=andrew.smirnov@gmail.com \
    --cc=andrew@aj.id.au \
    --cc=b.galvani@gmail.com \
    --cc=clg@kaod.org \
    --cc=edgar.iglesias@gmail.com \
    --cc=eduardo@habkost.net \
    --cc=f4bug@amsat.org \
    --cc=hskinnemoen@google.com \
    --cc=i.mitsyanko@gmail.com \
    --cc=jcd@tribudubois.net \
    --cc=joel@jms.id.au \
    --cc=kfting@nuvoton.com \
    --cc=michal.simek@xilinx.com \
    --cc=nieklinnenbank@gmail.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=robh@kernel.org \
    --cc=sstabellini@kernel.org \
    --cc=wangyanan55@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.