Peter Maydell writes:
> The sdcard_legacy.h header defines function prototypes for the "legacy"
> SD card API, which was used by non-qdevified SD controller models.
> We've now converted the only remaining non-qdev SD controller, so
> we can drop the legacy API.
>
> Entirely unused functions:
>
Hello Steven,
On 1/8/25 04:51, Steven Lee wrote:
Hi Cédric,
-Original Message-
From: Cédric Le Goater
Sent: Tuesday, January 7, 2025 11:51 PM
To: Steven Lee ; Peter Maydell
; Troy Lee ; Jamin Lin
; Andrew Jeffery
; Joel Stanley ; open
list:ASPEED BMCs ; open list:All patches CC here
Hello Jamin,
On 1/21/25 08:04, Jamin Lin wrote:
v1:
1. Refactor INTC model to support both INTC0 and INTC1.
2. Support AST2700 A1.
3. Create ast2700a0-evb machine.
With the patch applied, QEMU now supports two machines for running AST2700 SoCs:
ast2700a0-evb: Designed for AST2700 A0
as
On Fri, Jan 31, 2025 at 6:04 AM Sahil Siddiq wrote:
>
> Hi,
>
> On 1/24/25 1:04 PM, Eugenio Perez Martin wrote:
> > On Fri, Jan 24, 2025 at 6:47 AM Sahil Siddiq wrote:
> >> On 1/21/25 10:07 PM, Eugenio Perez Martin wrote:
> >>> On Sun, Jan 19, 2025 at 7:37 AM Sahil Siddiq
> >>> wrote:
> On
On 2025/01/30 19:37, Philippe Mathieu-Daudé wrote:
(Series fully reviewed)
Since v1:
- Use g_strconcat (Akihiko)
In preparation of running QTests using HVF on Darwin,
make qtest_has_accel() generic.
Note, this also allow running other accelerators such
Xen, WHPX, ...
Philippe Mathieu-Daudé (2
Hi,
On 1/24/25 1:04 PM, Eugenio Perez Martin wrote:
On Fri, Jan 24, 2025 at 6:47 AM Sahil Siddiq wrote:
On 1/21/25 10:07 PM, Eugenio Perez Martin wrote:
On Sun, Jan 19, 2025 at 7:37 AM Sahil Siddiq wrote:
On 1/7/25 1:35 PM, Eugenio Perez Martin wrote:
[...]
Apologies for the delay in replyi
Hi Paolo,
It has been a long time :-) Nowadays I work on Xen on both ARM and AMD
x86, and our x86 configuration has only hardware-assisted guests (PVH
guests). Even Dom0 is hardware-assisted.
I am trying to run Xen with Dom0 as PVH guest in QEMU TCG. If I enable
KVM, it works, but with KVM disab
On Fri, Jan 17, 2025 at 2:13 AM Vasilis Liaskovitis
wrote:
>
> Add an "aliases" node with a "serial0" entry for the single UART
> in the riscv virt machine.
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2774
> Signed-off-by: Vasilis Liaskovitis
> Reviewed-by: Andrew Jones
Thanks!
I've been following the recent changes to better support denormal handling and
I don't think they are doing the right thing for x86.
I tried a simple program to convert a denormal float value (0x1.0p-127) to a
double. With the default of DAZ being 0 in MXCSR, x86 sets DE, but QEMU
doesn't. Th
On Fri, Jan 17, 2025 at 2:13 AM Vasilis Liaskovitis
wrote:
>
> Add an "aliases" node with a "serial0" entry for the single UART
> in the riscv virt machine.
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2774
> Signed-off-by: Vasilis Liaskovitis
> Reviewed-by: Andrew Jones
Reviewed
On Wed, Jan 15, 2025 at 7:23 AM Rodrigo Dias Correa wrote:
>
> Instead of migrating the raw tick_offset, goldfish_rtc migrates a
> recalculated value based on QEMU_CLOCK_VIRTUAL. As QEMU_CLOCK_VIRTUAL
> stands still across a save-and-restore cycle, the guest RTC becomes out
> of sync with the host
On Fri, Jan 10, 2025 at 3:33 PM Sam Price wrote:
>
> Yes that is true a boot loader will do more than just set registers.
> Ill rework the text a bit on the next update.
> In my case i need to set the r5 register that specifies the memory
> location to the device tree.
Should that be done in the
On Wed, Jan 22, 2025 at 6:11 PM Jason Chien wrote:
>
> Ping
>
> Jason Chien 於 2025年1月15日 週三 下午10:17寫道：
>>
>> Initially, the IOMMU would create a thread, but this thread was removed in
>> the merged version. The struct members for thread control should have been
>> removed as well, but they were n
On Thu, Jan 16, 2025 at 4:44 AM Daniel Henrique Barboza
wrote:
>
> Hi,
>
> This new version has tweaks suggested by Drew in v3. No major changes
> were made.
>
> Patches based on alistair/riscv-to-apply.next.
>
> All patches acked.
>
> Changes from v3:
> - patch 3:
> - fix commit msg
> - drop
On Thu, Jan 16, 2025 at 12:18 AM Jason Chien wrote:
>
> The header contains duplicate macro definitions.
> This commit eliminates the duplicate part.
>
> Signed-off-by: Jason Chien
> Reviewed-by: Daniel Henrique Barboza
> Reviewed-by: Andrew Jones
Reviewed-by: Alistair Francis
Alistair
> --
On Thu, Jan 9, 2025 at 7:13 PM Ivan Klokov wrote:
>
> These patches add functionality for unit testing RISC-V-specific registers.
> The first patch adds a Qtest backend, and the second implements a simple test.
>
> ---
> v9:
>- Fix build errors.
> v8:
>- Delete RFC label.
> v7:
>- Fix
On Wed, Jan 15, 2025 at 7:23 AM Rodrigo Dias Correa wrote:
>
> Instead of migrating the raw tick_offset, goldfish_rtc migrates a
> recalculated value based on QEMU_CLOCK_VIRTUAL. As QEMU_CLOCK_VIRTUAL
> stands still across a save-and-restore cycle, the guest RTC becomes out
> of sync with the host
On Thu, Jan 16, 2025 at 4:45 AM Daniel Henrique Barboza
wrote:
>
> Add RVA23U64 as described in [1]. Add it as a child of RVA22U64 since
> all RVA22U64 mandatory extensions are also present in RVA23U64. What's
> left then is to list the mandatory extensions that are RVA23 only.
>
> A new "rva23u64
On Thu, Jan 16, 2025 at 4:45 AM Daniel Henrique Barboza
wrote:
>
> The S profiles do a priv_ver check during validation to see if the
> running priv_ver is compatible with it. This check is done by comparing
> if the running priv_ver is equal to the priv_ver the profile specifies.
>
> There is an
On Thu, Jan 16, 2025 at 12:19 AM Jason Chien wrote:
>
> Initially, the IOMMU would create a thread, but this thread was removed in
> the merged version. The struct members for thread control should have been
> removed as well, but they were not removed in commit 0c54acb8243
> ("hw/riscv: add RISC-
On Thu, Jan 16, 2025 at 4:45 AM Daniel Henrique Barboza
wrote:
>
> Add RVA23S64 as described in [1]. This profile inherits all mandatory
> extensions of RVA23U64 and RVA22S64, making it a child of both profiles.
>
> A new "rva23s64" profile CPU is also added. This is the generated
> riscv,isa for
On Thu, Jan 16, 2025 at 4:45 AM Daniel Henrique Barboza
wrote:
>
> The current 'parent' mechanic for profiles allows for one profile to be
> a child of a previous/older profile, enabling all its extensions (and
> the parent profile itself) and sparing us from tediously listing all
> extensions for
On Thu, Jan 16, 2025 at 4:45 AM Daniel Henrique Barboza
wrote:
>
> ssu64xl is defined in RVA22 as:
>
> "sstatus.UXL must be capable of holding the value 2 (i.e., UXLEN=64 must
> be supported)."
>
> This is always true in TCG and it's mandatory for RVA23, so claim
> support for it.
>
> Signed-off-b
On Thu, Jan 16, 2025 at 4:45 AM Daniel Henrique Barboza
wrote:
>
> From the time we added RVA22U64 until now the spec didn't declare 'RVB'
> as a dependency, using zba/zbb/zbs instead. Since then the RVA22 spec
> [1] added the following in the 'RVA22U64 Mandatory Extensions' section:
>
> "B Bit-ma
Cc'ing AMD folks
Hi Bernhard,
TL;DR; can't you use the PCF8574 which is a more complete model of I/O
expander? (See hw/gpio/pcf8574.c)
On 20/1/25 21:37, Bernhard Beschow wrote:
Xilinx QEMU implements a TCA6416 device model which may be useful for the
broader QEMU community, so upstream it. In
On 19/12/24 01:48, Bernhard Beschow wrote:
Am 12. Dezember 2024 08:52:07 UTC schrieb Nicholas Piggin :
The TI TUSB73X0 controller has some interesting differences from NEC,
notably a separate BAR for MSIX, and PM capabilities. The spec is freely
available without sign-up.
This controller is a
On Mon, Jan 27, 2025 at 8:40 AM Peter Maydell
wrote:
> Edgar or Alistair -- could one of you review this
> cadence GEM patch, please?
>
>
Sorry for the delay!
> On Thu, 19 Dec 2024 at 06:17, Andrew.Yuan
> wrote:
> >
> > From: Andrew Yuan
> >
> > As in the Cadence IP for Gigabit Ethernet MAC
On 28/1/25 11:45, Peter Maydell wrote:
Do a minimal conversion of the omap_mmc device model to QDev.
In this commit we do the bare minimum to produce a working device:
* add the SysBusDevice parent_obj and the usual type boilerplate
* omap_mmc_init() now returns a DeviceState*
* reset is h
On 28/1/25 11:45, Peter Maydell wrote:
Convert the OMAP MMC controller to the new SDBus API:
* the controller creates an SDBus bus
* instead of sd_foo functions on the SDState object, call
sdbus_foo functions on the SDBus
* the board code creates a proper TYPE_SD_CARD object and attache
+Markus for commit 007d1dbf725 ("sd: Hide the qdev-but-not-quite thing
created by sd_init()").
On 28/1/25 11:45, Peter Maydell wrote:
The sdcard_legacy.h header defines function prototypes for the "legacy"
SD card API, which was used by non-qdevified SD controller models.
We've now converted the
On 28/1/25 11:45, Peter Maydell wrote:
This is a very old source file, and still has some lingering
hard-coded tabs; untabify it.
Signed-off-by: Peter Maydell
---
I don't propose to try to bring the whole file up to modern
coding style, but hard-coded tabs are a particular wart.
---
hw/sd/oma
On 28/1/25 11:45, Peter Maydell wrote:
Now that sd_enable() has been removed, SD::enable is set to true in
sd_instance_init() and then never changed. So we can remove it.
Note that the VMSTATE_UNUSED() size argument should be '1', not
'sizeof(bool)', as noted in the CAUTION comment in vmstate.h.
On 28/1/25 11:45, Peter Maydell wrote:
The coverswitch qemu_irq is never connected to anything, and the only thing
we do with it is set it in omap_mmc_reset(). Remove it.
Signed-off-by: Peter Maydell
---
hw/sd/omap_mmc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/hw/sd/omap_mmc.c b
On 28/1/25 11:45, Peter Maydell wrote:
Our style for other conversions of OMAP devices to qdev has been to
inline the creation and wiring into omap310_mpu_init() -- see for
instance the handling of omap-intc, omap-gpio and omap_i2c. Do
the same for omap-mmc.
Signed-off-by: Peter Maydell
---
h
On 28/1/25 11:45, Peter Maydell wrote:
The approach we've settled on for handling the omap_clk wiring for
OMAP devices converted to QDev is to have a function omap_foo_set_clk()
whose implementation just sets the field directly in the device's
state struct. (See the "TODO" comment near the top of
On 28/1/25 11:45, Peter Maydell wrote:
The omap_mmc device has three outbound qemu_irq lines:
* one actual interrupt line
* two which connect to the DMA controller and are signalled for
TX and RX DMA
Convert these to a sysbus IRQ and two named GPIO outputs.
Signed-off-by: Peter Maydell
On 28/1/25 11:45, Peter Maydell wrote:
Mechanically convert the remaining uses of 'struct omap_mmc_s' to
'OMAPMMCState'.
Signed-off-by: Peter Maydell
---
include/hw/arm/omap.h | 2 +-
hw/sd/omap_mmc.c | 20 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff
On 24/1/25 13:47, BALATON Zoltan wrote:
The variable is uint64_t so needs %PRIu64 instead of %d.
Fixes: 3ae7eb88c47 ("ehci: fix overflow in frame timer code")
Signed-off-by: BALATON Zoltan
Reviewed-by: Peter Maydell
---
v3: Fixed commit message to match what the patch actually does
hw/usb/h
On 21/1/25 19:24, Philippe Mathieu-Daudé wrote:
The FPGA exposes a fixed set of IRQs. Hold them in the FPGA
state and initialize them in place calling qemu_init_irqs().
Move r2d_fpga_irq enums earlier so we can use NR_IRQS within
the r2d_fpga_t structure. r2d_fpga_init() returns r2d_fpga_t,
and
On 21/1/25 19:28, Philippe Mathieu-Daudé wrote:
There are a fixed number of PCI IRQs, known beforehand.
Allocate them within PCIMultiSerialState, and initialize
using qemu_init_irq(), allowing to remove the legacy
qemu_allocate_irqs() and qemu_free_irqs() calls.
Signed-off-by: Philippe Mathieu-D
On 21/1/25 16:55, Philippe Mathieu-Daudé wrote:
Philippe Mathieu-Daudé (3):
hw/irq: Introduce qemu_init_irqs() helper
hw/ipack: Clarify KConfig symbols
hw/ipack: Remove legacy qemu_allocate_irqs() use
Series queued.
On 27/1/25 12:38, Philippe Mathieu-Daudé wrote:
Philippe Mathieu-Daudé (6):
hw/avr/boot: Replace load_elf_ram_sym() -> load_elf_as()
hw/loader: Remove unused load_elf_ram()
hw/loader: Clarify local variable name in load_elf_ram_sym()
Thanks, series queued squashing:
-- >8--
diff --g
On 1/30/25 11:08, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
So it can be safety accessed from multiple threads.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/vfio/migration.c b/hw/vfio/mi
On Thu, Jan 30, 2025 at 08:27:12PM +0100, Thomas Huth wrote:
> By using the serial console instead of ssh for executing commands
> in the guest, we can convert this test to the functional framework.
>
> Signed-off-by: Thomas Huth
> ---
> MAINTAINERS | 1 +
> te
On 1/30/25 18:55, Alex Williamson wrote:
On Thu, 30 Jan 2025 14:43:38 +0100
Cédric Le Goater wrote:
Depending on the configuration, a passthrough device may produce
recurring DMA mapping errors at runtime and produce a lot of
output. It is useful to report only once.
Cc: Markus Armbruster
Si
On Thu, Jan 30, 2025 at 03:40:10PM -0300, Fabiano Rosas wrote:
> Hi, continuing the work from the previous[1] series to reduce the time
> migration-test takes during make check, here's a couple of patches to
> create a smaller set of tests.
>
> The change is that from now on, ./migration-test will
On Thu, Jan 30, 2025 at 06:12:35PM +0100, Kevin Wolf wrote:
> An active node makes unrestricted use of its children and would possibly
> run into assertion failures when it operates on an inactive child node.
>
> Signed-off-by: Kevin Wolf
> ---
> block.c | 5 +
> 1 file changed, 5 insertions
On Thu, Jan 30, 2025 at 05:11:36PM +0100, Juraj Marcin wrote:
> When there are no page requests from the destination side and the
> connection breaks, the destination might not be aware of it. This is
> the case for example with a TCP connection, which by default remains
> open unless it is explici
On Thu, Jan 30, 2025 at 06:12:40PM +0100, Kevin Wolf wrote:
> Device models have a relatively complex way to set up their block
> backends, in which blk_attach_dev() sets blk->disable_perm = true.
> We want to support inactive images in exports, too, so that
> qemu-storage-daemon can be used with m
"Maciej S. Szmigiero" writes:
> On 30.01.2025 21:19, Fabiano Rosas wrote:
>> "Maciej S. Szmigiero" writes:
>>
>>> From: "Maciej S. Szmigiero"
>>>
>>> This is an updated v4 patch series of the v3 series located here:
>>> https://lore.kernel.org/qemu-devel/cover.1731773021.git.maciej.szmigi...@o
On Wed, Jan 22, 2025 at 12:50:43PM +0100, Kevin Wolf wrote:
> In order to support running an NBD export on inactive nodes, we must
> make sure to return errors for any operations that aren't allowed on
> inactive nodes. Reads are the only operation we know we need for
> inactive images, so to err o
On Fri, 31 Jan 2025 02:33:03 +0800
Tomita Moeko wrote:
> On 1/25/25 15:42, Tomita Moeko wrote:
> > On 1/25/25 05:13, Alex Williamson wrote:
> >> On Sat, 25 Jan 2025 03:12:45 +0800
> >> Tomita Moeko wrote:
> >>
> >>> Both enable opregion option (x-igd-opregion) and legacy mode require
> >>> s
The following changes since commit 871af84dd599fab68c8ed414d9ecbdb2bcfc5801:
Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
(2025-01-29 09:51:03 -0500)
are available in the Git repository at:
https://gitlab.com/stefanha/qemu.git tags/block-pull-request
for you to
From: Denis Rastyogin
This error was discovered by fuzzing qemu-img.
When ph.ext_off has a sufficiently large value, the operation
le64_to_cpu(ph.ext_off) << BDRV_SECTOR_BITS in
parallels_read_format_extension() can cause an overflow in int64_t.
This overflow triggers the assert(ext_off > 0)
che
"Maciej S. Szmigiero" writes:
> From: "Maciej S. Szmigiero"
>
> This is an updated v4 patch series of the v3 series located here:
> https://lore.kernel.org/qemu-devel/cover.1731773021.git.maciej.szmigi...@oracle.com/
>
> Changes from v3:
> * MigrationLoadThread now returns bool and an Error comp
On 30.01.2025 21:19, Fabiano Rosas wrote:
"Maciej S. Szmigiero" writes:
From: "Maciej S. Szmigiero"
This is an updated v4 patch series of the v3 series located here:
https://lore.kernel.org/qemu-devel/cover.1731773021.git.maciej.szmigi...@oracle.com/
Changes from v3:
* MigrationLoadThread n
On Thu, Jan 30, 2025 at 06:12:38PM +0100, Kevin Wolf wrote:
> In QEMU, nodes are automatically created inactive while expecting an
> incoming migration (i.e. RUN_STATE_INMIGRATE). In qemu-storage-daemon,
> the notion of runstates doesn't exist. It also wouldn't necessarily make
> sense to introduce
On Thu, Jan 30, 2025 at 06:12:39PM +0100, Kevin Wolf wrote:
> The system emulator tries to automatically activate and inactivate block
> nodes at the right point during migration. However, there are still
> cases where it's necessary that the user can do this manually.
>
> Images are only activate
On Thu, Jan 30, 2025 at 06:12:37PM +0100, Kevin Wolf wrote:
> In order for block_resize to fail gracefully on an inactive node instead
> of crashing with an assertion failure in bdrv_co_write_req_prepare()
> (called from bdrv_co_truncate()), we need to check for inactive nodes
> also when they are
On Thu, Jan 30, 2025 at 06:12:36PM +0100, Kevin Wolf wrote:
> What we wanted to catch with the assertion is cases where the recursion
> finds that a child was inactive before its parent. This should never
> happen. But if the user tries to inactivate an image that is already
> inactive, that's harm
On Thu, Jan 30, 2025 at 06:12:34PM +0100, Kevin Wolf wrote:
> Block devices have an individual active state, a single global flag
> can't cover this correctly. This becomes more important as we allow
> users to manually manage which nodes are active or inactive.
>
> Now that it's allowed to call b
On Thu, Jan 30, 2025 at 06:12:33PM +0100, Kevin Wolf wrote:
> Putting an active block node on top of an inactive one is strictly
> speaking an invalid configuration and the next patch will turn it into a
> hard error.
>
> However, taking a snapshot while disk images are inactive after
> completing
On 30/1/25 19:30, Peter Maydell wrote:
On Thu, 30 Jan 2025 at 18:25, Philippe Mathieu-Daudé wrote:
When not specified, Cortex-A9MP configures its GIC with 64 external
IRQs (see commit a32134aad89 "arm:make the number of GIC interrupts
configurable"). Add the GIC_EXT_IRQS definition (with a com
On Thu, Jan 30, 2025 at 06:12:32PM +0100, Kevin Wolf wrote:
> This allows querying from QMP (and also HMP) whether an image is
> currently active or inactive (in the sense of BDRV_O_INACTIVE).
>
> Signed-off-by: Kevin Wolf
> ---
> +++ b/block/qapi.c
> @@ -63,6 +63,7 @@ BlockDeviceInfo *bdrv_bloc
By using the serial console instead of ssh for executing commands
in the guest, we can convert this test to the functional framework.
Signed-off-by: Thomas Huth
---
MAINTAINERS | 1 +
tests/functional/meson.build | 1 +
.../test_x86_64_hotplug
On Wed, Jan 22, 2025 at 12:50:37PM +0100, Kevin Wolf wrote:
> This series adds a mechanism that allows the user or management tool to
> manually activate and inactivate block nodes instead of fully relying on
> the automatic management in the migration code.
>
> One case where this is needed is fo
30.01.2025 16:29, del...@kernel.org wrote:
diff --git a/target/hppa/translate.c b/target/hppa/translate.c
+if (ctx->is_pa20 && (a->dr == 2)) {
+/* Update gva_offset_mask from the new value of %dr2 */
+gen_helper_update_gva_offset_mask(tcg_env);
+/* Exit to capture
On Wed, Jan 22, 2025 at 12:50:42PM +0100, Kevin Wolf wrote:
> Add an option in BlockExportOptions to allow creating an export on an
> inactive node without activating the node. This mode needs to be
> explicitly supported by the export type (so that it doesn't perform any
> operations that are forb
On Wed, Jan 22, 2025 at 12:50:41PM +0100, Kevin Wolf wrote:
> Currently, block jobs can't handle inactive images correctly. Incoming
> write requests would run into assertion failures. Make sure that we
> return an error when creating an export can't activate the image.
>
> Signed-off-by: Kevin Wo
On Thu, 30 Jan 2025 14:43:45 +0100
Cédric Le Goater wrote:
> Print a warning if IOMMU address space width is smaller than the
> physical address width. In this case, PCI peer-to-peer transactions on
> BARs are not supported and failures of device MMIO regions are to be
> expected.
>
> This can o
On Wed, Jan 22, 2025 at 12:50:40PM +0100, Kevin Wolf wrote:
> Device models have a relatively complex way to set up their block
> backends, in which blk_attach_dev() sets blk->disable_perm = true.
> We want to support inactive images in exports, too, so that
> qemu-storage-daemon can be used with m
On Wed, Jan 22, 2025 at 12:50:39PM +0100, Kevin Wolf wrote:
> In QEMU, nodes are automatically created inactive while expecting an
> incoming migration (i.e. RUN_STATE_INMIGRATE). In qemu-storage-daemon,
> the notion of runstates doesn't exist. It also wouldn't necessarily make
> sense to introduce
On Wed, Jan 22, 2025 at 12:50:38PM +0100, Kevin Wolf wrote:
> What we wanted to catch with the assertion is cases where the recursion
> finds that a child was inactive before its parent. This should never
> happen. But if the user tries to inactivate an image that is already
> inactive, that's harm
Add a new command line option to allow selecting between running the
full set of tests or a smaller set of tests. The default will be to
run the small set (i.e. no comand line option provided) so we can
reduce the amount of tests run by default. Only hosts which support
KVM for the target architect
Choose a few tests per group and move them from the full set to the
smoke set.
Signed-off-by: Fabiano Rosas
---
tests/qtest/migration-test.c | 1 -
tests/qtest/migration/compression-tests.c | 11 ++---
tests/qtest/migration/cpr-tests.c | 2 ++
tests/qtest/migration/fil
Hi, continuing the work from the previous[1] series to reduce the time
migration-test takes during make check, here's a couple of patches to
create a smaller set of tests.
The change is that from now on, ./migration-test will only run a
limited set of tests (~12), while the full set (64) requires
On Thu, 30 Jan 2025 at 18:25, Philippe Mathieu-Daudé wrote:
>
> When not specified, Cortex-A9MP configures its GIC with 64 external
> IRQs (see commit a32134aad89 "arm:make the number of GIC interrupts
> configurable"). Add the GIC_EXT_IRQS definition (with a comment)
> to make that explicit.
>
>
In the gicv3_{irq,fiq,irqfiq}_access() functions, there is a check
which downgrades a CP_ACCESS_TRAP_EL3 to CP_ACCESS_TRAP if EL3 is not
AArch64. This has been there since the GIC was first implemented,
but it isn't right: if we are trapping because of SCR.IRQ or SCR.FIQ
then we definitely want to
On 1/25/25 15:42, Tomita Moeko wrote:
> On 1/25/25 05:13, Alex Williamson wrote:
>> On Sat, 25 Jan 2025 03:12:45 +0800
>> Tomita Moeko wrote:
>>
>>> Both enable opregion option (x-igd-opregion) and legacy mode require
>>> setting up OpRegion copy for IGD devices. Move x-igd-opregion handler
>>> in
On Thu, 30 Jan 2025 at 18:25, Philippe Mathieu-Daudé wrote:
>
> When not specified, Cortex-A9MP configures its GIC with 64 external
> IRQs (see commit a32134aad89 "arm:make the number of GIC interrupts
> configurable"). Add the GIC_EXT_IRQS definition (with a comment)
> to make that explicit.
>
>
On 1/30/25 07:52, Jonathan Cameron wrote:
On Wed, 29 Jan 2025 14:31:10 -0800
Pierrick Bouvier wrote:
Hi Jonathan,
On 1/29/25 02:29, Jonathan Cameron wrote:
On Tue, 28 Jan 2025 12:04:19 -0800
Pierrick Bouvier wrote:
On 1/27/25 02:20, Jonathan Cameron wrote:
On Fri, 24 Jan 2025 12:55:52
Implicit default values are often hard to figure out, better
be explicit. Now that all boards explicitly set the number of
GIC external IRQs, remove the default values (displaying an
error message if it is not set).
Signed-off-by: Philippe Mathieu-Daudé
---
hw/cpu/a15mpcore.c | 13 ++---
We already have a definition to distinct GIC internal
IRQs versus external ones, use it. No logical changes.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/xilinx_zynq.c | 34 --
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/hw/arm/xilinx_zynq.
When not specified, Cortex-A9MP configures its GIC with 64 external
IRQs (see commit a32134aad89 "arm:make the number of GIC interrupts
configurable"). Add the GIC_EXT_IRQS definition (with a comment)
to make that explicit.
Except explicitly setting a property value to its same implicit
value, the
Some boards based on Cortex-A9MP / Cortex-A15MP do not explicit
the number of external GIC IRQs, using some (implicit) default value,
not always trivial to figure out. Change that by removing the default
value, requiring MPCore objects to be created with the "num-irq" set.
Philippe Mathieu-Daudé (
When not specified, Cortex-A9MP configures its GIC with 64 external
IRQs (see commit a32134aad89 "arm:make the number of GIC interrupts
configurable"). Add the GIC_EXT_IRQS definition (with a comment)
to make that explicit.
Except explicitly setting a property value to its same implicit
value, the
When not specified, Cortex-A9MP configures its GIC with 64 external
IRQs, (see commit a32134aad89 "arm:make the number of GIC interrupts
configurable"), and Cortex-15MP to 128 (see commit 528622421eb
"hw/cpu/a15mpcore: Correct default value for num-irq").
The Versatile Express board however expect
When not specified, Cortex-A9MP configures its GIC with 64 external
IRQs (see commit a32134aad89 "arm:make the number of GIC interrupts
configurable"). Add the GIC_EXT_IRQS definition (with a comment)
to make that explicit.
Except explicitly setting a property value to its same implicit
value, the
When not specified, Cortex-A9MP configures its GIC with 64 external
IRQs, (see commit a32134aad89 "arm:make the number of GIC interrupts
configurable"), and Cortex-15MP to 128 (see commit 528622421eb
"hw/cpu/a15mpcore: Correct default value for num-irq").
The Caldexa Highbank board however expects
While reviewing Alex's recent secure timer patchset, I noticed a
bug where it was using CP_ACCESS_TRAP when CP_ACCESS_TRAP_UNCATEGORIZED
was wanted, and that we were making the same mistake elsewhere in
our existing code. This series started out as an attempt to fix
that and also rearrange the API
The 32 IRQ lines skipped are the GIC internal ones.
Use the GIC_INTERNAL definition for clarity.
No logical change.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/exynos4210.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/arm/exynos4210.c b/hw/arm/exynos4210.c
in
There are no longer any uses of CP_ACCESS_TRAP in access functions,
because we have converted them all to use either CP_ACCESS_TRAP_EL1
or CP_ACCESS_TRAP_UNCATEGORIZED, as appropriate. Remove the handling
of bare CP_ACCESS_TRAP from the access_check_cp_reg() helper, so that
it now asserts if an acc
CP_ACCESS_TRAP_UNCATEGORIZED is technically an accurate description
of what this return value from a cpreg accessfn does, but it's liable
to confusion because it doesn't match how the Arm ARM pseudocode
indicates this case. What it does is an EXCP_UDEF with a zero
("uncategorized") syndrome value,
In the CPAccessResult enum, the CP_ACCESS_TRAP* values indicate the
equivalent of the pseudocode AArch64.SystemAccessTrap(..., 0x18),
causing a trap to a specified exception level with a syndrome value
giving information about the failing instructions. In the
pseudocode, such traps are always take
The pseudocode for the accessors for the LOR sysregs says they
are UNDEFINED if SCR_EL3.NS is 0. We were reporting the wrong
syndrome value here; use CP_ACCESS_TRAP_UNCATEGORIZED.
Cc: qemu-sta...@nongnu.org
Fixes: 2d7137c10faf ("target/arm: Implement the ARMv8.1-LOR extension")
Signed-off-by: Pete
In system register access pseudocode the common pattern for
AArch32 registers with access traps to EL3 is:
at EL1 and EL2:
if HaveEL(EL3) && !ELUsingAArch32(EL3) && (SCR_EL3.TERR == 1) then
AArch64.AArch32SystemAccessTrap(EL3, 0x03);
elsif HaveEL(EL3) && ELUsingAArch32(EL3) && (SCR.TERR =
We currently use CP_ACCESS_TRAP in a number of access functions where
we know we're currently at EL0; in this case the "usual target EL"
is EL1, so CP_ACCESS_TRAP and CP_ACCESS_TRAP_EL1 behave the same.
Use CP_ACCESS_TRAP_EL1 to more closely match the pseudocode for
this sort of check.
Note that i
There are not many traps in AArch32 which should trap to Monitor
mode, but these trap bits should trap not just lower ELs to Monitor
mode but also the non-Monitor modes running at EL3 (i.e. Secure
System, Secure Undef, etc).
We get this wrong because the relevant access functions implement the
AA
On XScale CPUs, there is no EL2 or AArch64, so no syndrome register.
These traps are just UNDEFs in the traditional AArch32 sense, so
CP_ACCESS_TRAP_UNCATEGORIZED is more accurate than CP_ACCESS_TRAP.
This has no visible behavioural change, because the guest doesn't
have a way to see the syndrome v
The pseudocode for AT S1E2R and AT S1E2W says that they should be
UNDEFINED if executed at EL3 when EL2 is not enabled. We were
incorrectly using CP_ACCESS_TRAP and reporting the wrong exception
syndrome as a result. Use CP_ACCESS_TRAP_UNCATEGORIZED.
Cc: qemu-sta...@nongnu.org
Fixes: 2a47df953202e
1 - 100 of 265 matches
Mail list logo
