aboutsummaryrefslogtreecommitdiff
path: root/hw/arm
AgeCommit message (Collapse)Author
2019-08-22Merge remote-tracking branch 'remotes/armbru/tags/pull-monitor-2019-08-21' ↵Peter Maydell
into staging Monitor patches for 2019-08-21 # gpg: Signature made Wed 21 Aug 2019 16:35:07 BST # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "armbru@redhat.com" # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * remotes/armbru/tags/pull-monitor-2019-08-21: monitor/qmp: Update comment for commit 4eaca8de268 qdev: Collect HMP handlers command handlers in qdev-monitor.c qapi: Move query-target from misc.json to machine.json hw/core: Move cpu.c, cpu.h from qom/ to hw/core/ Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-21hw/core: Move cpu.c, cpu.h from qom/ to hw/core/Markus Armbruster
Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190709152053.16670-2-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> [Rebased onto merge commit 95a9457fd44; missed instances of qom/cpu.h in comments replaced]
2019-08-21hw: add compat machines for 4.2Cornelia Huck
Add 4.2 machine types for arm/i440fx/q35/s390x/spapr. For i440fx and q35, unversioned cpu models are still translated to -v1, as 0788a56bd1ae ("i386: Make unversioned CPU models be aliases") states this should only transition to the latest cpu model version in 4.3 (or later). Signed-off-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20190724103524.20916-1-cohuck@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-20hw/misc: Add a config switch for the "unimplemented" deviceThomas Huth
The device is only used by some few boards. Let's use a proper Kconfig switch so that we only compile this code if we really need it. Message-Id: <20190817101931.28386-8-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2019-08-20hw/core: Add a config switch for the "split-irq" deviceThomas Huth
The "split-irq" device is currently only used by machines that use CONFIG_ARMSSE. Let's add a proper CONFIG_SPLIT_IRQ switch for this so that it only gets compiled when we really need it. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190817101931.28386-7-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2019-08-20hw/core: Add a config switch for the "or-irq" deviceThomas Huth
The "or-irq" device is only used by certain machines. Let's add a proper config switch for it so that it only gets compiled when we really need it. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190817101931.28386-6-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2019-08-16sysemu: Split sysemu/runstate.h off sysemu/sysemu.hMarkus Armbruster
sysemu/sysemu.h is a rather unfocused dumping ground for stuff related to the system-emulator. Evidence: * It's included widely: in my "build everything" tree, changing sysemu/sysemu.h still triggers a recompile of some 1100 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h, down from 5400 due to the previous two commits). * It pulls in more than a dozen additional headers. Split stuff related to run state management into its own header sysemu/runstate.h. Touching sysemu/sysemu.h now recompiles some 850 objects. qemu/uuid.h also drops from 1100 to 850, and qapi/qapi-types-run-state.h from 4400 to 4200. Touching new sysemu/runstate.h recompiles some 500 objects. Since I'm touching MAINTAINERS to add sysemu/runstate.h anyway, also add qemu/main-loop.h. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190812052359.30071-30-armbru@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> [Unbreak OS-X build]
2019-08-16Include sysemu/sysemu.h a lot lessMarkus Armbruster
In my "build everything" tree, changing sysemu/sysemu.h triggers a recompile of some 5400 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). hw/qdev-core.h includes sysemu/sysemu.h since recent commit e965ffa70a "qdev: add qdev_add_vm_change_state_handler()". This is a bad idea: hw/qdev-core.h is widely included. Move the declaration of qdev_add_vm_change_state_handler() to sysemu/sysemu.h, and drop the problematic include from hw/qdev-core.h. Touching sysemu/sysemu.h now recompiles some 1800 objects. qemu/uuid.h also drops from 5400 to 1800. A few more headers show smaller improvement: qemu/notify.h drops from 5600 to 5200, qemu/timer.h from 5600 to 4500, and qapi/qapi-types-run-state.h from 5500 to 5000. Cc: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20190812052359.30071-28-armbru@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
2019-08-16Clean up inclusion of sysemu/sysemu.hMarkus Armbruster
In my "build everything" tree, changing sysemu/sysemu.h triggers a recompile of some 5400 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). Almost a third of its inclusions are actually superfluous. Delete them. Downgrade two more to qapi/qapi-types-run-state.h, and move one from char/serial.h to char/serial.c. hw/semihosting/config.c, monitor/monitor.c, qdev-monitor.c, and stubs/semihost.c define variables declared in sysemu/sysemu.h without including it. The compiler is cool with that, but include it anyway. This doesn't reduce actual use much, as it's still included into widely included headers. The next commit will tackle that. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-27-armbru@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
2019-08-16Include hw/boards.h a bit lessMarkus Armbruster
hw/boards.h pulls in almost 60 headers. The less we include it into headers, the better. As a first step, drop superfluous inclusions, and downgrade some more to what's actually needed. Gets rid of just one inclusion into a header. Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-23-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
2019-08-16Include hw/qdev-properties.h lessMarkus Armbruster
In my "build everything" tree, changing hw/qdev-properties.h triggers a recompile of some 2700 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). Many places including hw/qdev-properties.h (directly or via hw/qdev.h) actually need only hw/qdev-core.h. Include hw/qdev-core.h there instead. hw/qdev.h is actually pointless: all it does is include hw/qdev-core.h and hw/qdev-properties.h, which in turn includes hw/qdev-core.h. Replace the remaining uses of hw/qdev.h by hw/qdev-properties.h. While there, delete a few superfluous inclusions of hw/qdev-core.h. Touching hw/qdev-properties.h now recompiles some 1200 objects. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Daniel P. Berrangé" <berrange@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190812052359.30071-22-armbru@redhat.com>
2019-08-16Include qemu/main-loop.h lessMarkus Armbruster
In my "build everything" tree, changing qemu/main-loop.h triggers a recompile of some 5600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). It includes block/aio.h, which in turn includes qemu/event_notifier.h, qemu/notify.h, qemu/processor.h, qemu/qsp.h, qemu/queue.h, qemu/thread-posix.h, qemu/thread.h, qemu/timer.h, and a few more. Include qemu/main-loop.h only where it's needed. Touching it now recompiles only some 1700 objects. For block/aio.h and qemu/event_notifier.h, these numbers drop from 5600 to 2800. For the others, they shrink only slightly. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190812052359.30071-21-armbru@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-16Include hw/hw.h exactly where neededMarkus Armbruster
In my "build everything" tree, changing hw/hw.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The previous commits have left only the declaration of hw_error() in hw/hw.h. This permits dropping most of its inclusions. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-19-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-16Include migration/vmstate.h lessMarkus Armbruster
In my "build everything" tree, changing migration/vmstate.h triggers a recompile of some 2700 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). hw/hw.h supposedly includes it for convenience. Several other headers include it just to get VMStateDescription. The previous commit made that unnecessary. Include migration/vmstate.h only where it's still needed. Touching it now recompiles only some 1600 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-16-armbru@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-16Include hw/irq.h a lot lessMarkus Armbruster
In my "build everything" tree, changing hw/irq.h triggers a recompile of some 5400 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). hw/hw.h supposedly includes it for convenience. Several other headers include it just to get qemu_irq and.or qemu_irq_handler. Move the qemu_irq and qemu_irq_handler typedefs from hw/irq.h to qemu/typedefs.h, and then include hw/irq.h only where it's still needed. Touching it now recompiles only some 500 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-13-armbru@redhat.com>
2019-08-16ide: Include hw/ide/internal a bit less outside hw/ide/Markus Armbruster
According to hw/ide/internal's file comment, only files in hw/ide/ are supposed to include it. Drag reality slightly closer to supposition. Three includes outside hw/ide remain: hw/arm/sbsa-ref.c, include/hw/ide/pci.h, and include/hw/misc/macio/macio.h. Turns out board code needs ide-internal.h to wire up IDE stuff. More cleanup is needed. Left for another day. Cc: John Snow <jsnow@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-11-armbru@redhat.com>
2019-08-16Include sysemu/reset.h a lot lessMarkus Armbruster
In my "build everything" tree, changing sysemu/reset.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The main culprit is hw/hw.h, which supposedly includes it for convenience. Include sysemu/reset.h only where it's needed. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-9-armbru@redhat.com>
2019-07-26hw/arm/boot: Further improve initrd positioning codePeter Maydell
In commit e6b2b20d9735d4ef we made the boot loader code try to avoid putting the initrd on top of the kernel. However the expression used to calculate the start of the initrd: info->initrd_start = info->loader_start + MAX(MIN(info->ram_size / 2, 128 * 1024 * 1024), kernel_size); incorrectly uses 'kernel_size' as the offset within RAM of the highest address to avoid. This is incorrect because the kernel doesn't start at address 0, but slightly higher than that. This means that we can still incorrectly end up overlaying the initrd on the kernel in some cases, for example: * The kernel's image_size is 0x0a7a8000 * The kernel was loaded at 0x40080000 * The end of the kernel is 0x4A828000 * The DTB was loaded at 0x4a800000 To get this right we need to track the actual highest address used by the kernel and use that rather than kernel_size. We already set image_low_addr and image_high_addr for ELF images; set them also for the various other image types we support, and then use image_high_addr as the lowest allowed address for the initrd. (We don't use image_low_addr, but we set it for consistency with the existing code path for ELF files.) Fixes: e6b2b20d9735d4ef Reported-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190722151804.25467-3-peter.maydell@linaro.org
2019-07-26hw/arm/boot: Rename elf_{low, high}_addr to image_{low, high}_addrPeter Maydell
Rename the elf_low_addr and elf_high_addr variables to image_low_addr and image_high_addr -- in the next commit we will extend them to be set for other kinds of image file and not just ELF files. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190722151804.25467-2-peter.maydell@linaro.org
2019-07-22hw/arm/fsl-imx6ul.c: Remove dead SMP-related codePeter Maydell
The i.MX6UL always has a single Cortex-A7 CPU (we set FSL_IMX6UL_NUM_CPUS to 1 in line with this). This means that all the code in fsl-imx6ul.c to handle multiple CPUs is dead code, and Coverity is now complaining that it is unreachable (CID 1403008, 1403011). Remove the unreachable code and the only-executes-once loops, and replace the single-entry cpu[] array in the FSLIMX6ULState with a simple cpu member. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190712115030.26895-1-peter.maydell@linaro.org
2019-07-15hw/arm/virt: Fix non-secure flash modeDavid Engraf
Using the whole 128 MiB flash in non-secure mode is not working because virt_flash_fdt() expects the same address for secure_sysmem and sysmem. This is not correctly handled by caller because it forwards NULL for secure_sysmem in non-secure flash mode. Fixed by using sysmem when secure_sysmem is NULL. Signed-off-by: David Engraf <david.engraf@sysgo.com> Message-id: 20190712075002.14326-1-david.engraf@sysgo.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-08hw/arm/sbsa-ref: Remove unnecessary check for secure_sysmem == NULLPeter Maydell
In the virt machine, we support TrustZone being either present or absent, and so the code must deal with the secure_sysmem pointer possibly being NULL. In the sbsa-ref machine, TrustZone is always present, but some code and comments copied from virt still treat it as possibly not being present. This causes Coverity to complain (CID 1407287) that we check secure_sysmem for being NULL after an unconditional dereference. Simplify the code so that instead of initializing the variable to NULL, unconditionally assigning it, and then testing it for NULL, we just initialize it correctly in the variable declaration and then assume it to be non-NULL. We also delete a comment which only applied to the non-TrustZone config. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190704142004.7150-1-peter.maydell@linaro.org Tested-by: Radosław Biernacki <radoslaw.biernacki@linaro.org> Reviewed-by: Radosław Biernacki <radoslaw.biernacki@linaro.org>
2019-07-05machine: show if CLI option '-numa node,mem' is supported in QAPI schemaIgor Mammedov
Legacy '-numa node,mem' option has a number of issues and mgmt often defaults to it. Unfortunately it's no possible to replace it with an alternative '-numa memdev' without breaking migration compatibility. What's possible though is to deprecate it, keeping option working with old machine types only. In order to help users to find out if being deprecated CLI option '-numa node,mem' is still supported by particular machine type, add new "numa-mem-supported" property to output of query-machines. "numa-mem-supported" is set to 'true' for machines that currently support NUMA, but it will be flipped to 'false' later on, once deprecation period expires and kept 'true' only for old machine types that used to support the legacy option so it won't break existing configuration that are using it. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1560172207-378962-1-git-send-email-imammedo@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-07-05hw/arm: Replace global smp variables with machine smp propertiesLike Xu
The global smp variables in arm are replaced with smp machine properties. The init_cpus() and *_create_rpu() are refactored to pass MachineState. A local variable of the same name would be introduced in the declaration phase if it's used widely in the context OR replace it on the spot if it's only used once. No semantic changes. Signed-off-by: Like Xu <like.xu@linux.intel.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190518205428.90532-9-like.xu@linux.intel.com> [ehabkost: Fix hw/arm/sbsa-ref.c and hw/arm/aspeed.c] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-07-05machine: Refactor smp-related call chains to pass MachineStateLike Xu
To get rid of the global smp_* variables we're currently using, it's recommended to pass MachineState in the list of incoming parameters for functions that use global smp variables, thus some redundant parameters are dropped. It's applied for legacy smbios_*(), *_machine_reset(), hot_add_cpu() and mips *_create_cpu(). Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Like Xu <like.xu@linux.intel.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190518205428.90532-3-like.xu@linux.intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-07-01hw/arm: Add arm SBSA reference machine, devices partHongbo Zhang
Following the previous patch, this patch adds peripheral devices to the newly introduced SBSA-ref machine. Signed-off-by: Hongbo Zhang <hongbo.zhang@linaro.org> Message-id: 1561890034-15921-3-git-send-email-hongbo.zhang@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01hw/arm: Add arm SBSA reference machine, skeleton partHongbo Zhang
For AArch64, the existing "virt" machine is primarily meant to run on KVM and execute virtualization workloads, but we need an environment as faithful as possible to physical hardware, for supporting firmware and OS development for physical Aarch64 machines. This patch introduces new machine type 'sbsa-ref' with main features: - Based on 'virt' machine type. - A new memory map. - CPU type cortex-a57. - EL2 and EL3 are enabled. - GIC version 3. - System bus AHCI controller. - System bus EHCI controller. - CDROM and hard disc on AHCI bus. - E1000E ethernet card on PCIE bus. - VGA display adaptor on PCIE bus. - No virtio devices. - No fw_cfg device. - No ACPI table supplied. - Only minimal device tree nodes. Arm Trusted Firmware and UEFI porting to this are done accordingly, and the firmware should supply ACPI tables to the guest OS. The minimal device tree nodes supplied by QEMU for this platform are only to pass the dynamic info reflecting command line input to firmware, not for loading the guest OS. To make the review easier, this task is split into two patches, the fundamental skeleton part and the peripheral devices part; this patch is the first part. Signed-off-by: Hongbo Zhang <hongbo.zhang@linaro.org> Message-id: 1561890034-15921-2-git-send-email-hongbo.zhang@linaro.org [PMM: commit message tweaks; moved some bits between patch 1 and 2 to ensure patch 1 builds cleanly; removed unneeded lines from Kconfig stanza; only provide board for qemu-system-aarch64, not qemu-system-arm; added MAINTAINERS entry] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01aspeed: Link SCU to the watchdogJoel Stanley
The ast2500 uses the watchdog to reset the SDRAM controller. This operation is usually performed by u-boot's memory training procedure, and it is enabled by setting a bit in the SCU and then causing the watchdog to expire. Therefore, we need the watchdog to be able to access the SCU's register space. This causes the watchdog to not perform a system reset when the bit is set. In the future it could perform a reset of the SDMC model. Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190621065242.32535-1-joel@jms.id.au Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01hw/misc/aspeed_xdma: New deviceEddie James
The XDMA engine embedded in the Aspeed SOCs performs PCI DMA operations between the SOC (acting as a BMC) and a host processor in a server. The XDMA engine exists on the AST2400, AST2500, and AST2600 SOCs, so enable it for all of those. Add trace events on the important register writes in the XDMA engine. Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-id: 20190618165311.27066-21-clg@kaod.org [clg: - changed title ] Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01aspeed: Add support for the swift-bmc boardAdriana Kobylak
The Swift board is an OpenPOWER system hosting POWER processors. Add support for their BMC including the I2C devices as found on HW. Signed-off-by: Adriana Kobylak <anoo@us.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Message-id: 20190618165311.27066-20-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01aspeed/smc: add a 'sdram_base' propertyCédric Le Goater
The DRAM address of a DMA transaction depends on the DRAM base address of the SoC. Inform the SMC controller model with this value. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190618165311.27066-15-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01aspeed: add a RAM memory region containerCédric Le Goater
The RAM memory region is defined after the SoC is realized when the SDMC controller has checked that the defined RAM size for the machine is correct. This is problematic for controller models requiring a link on the RAM region, for DMA support in the SMC controller for instance. Introduce a container memory region for the RAM that we can link into the controllers early, before the SoC is realized. It will be populated with the RAM region after the checks have be done. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Message-id: 20190618165311.27066-14-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01aspeed: remove the "ram" linkCédric Le Goater
It has never been used as far as I can tell from the git history. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Message-id: 20190618165311.27066-13-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01aspeed: add support for multiple NICsCédric Le Goater
The Aspeed SoCs have two MACs. Extend the Aspeed model to support a second NIC. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Message-id: 20190618165311.27066-7-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01aspeed: introduce a configurable number of CPU per machineCédric Le Goater
The current models of the Aspeed SoCs only have one CPU but future ones will support SMP. Introduce a new num_cpus field at the SoC class level to define the number of available CPUs per SoC and also introduce a 'num-cpus' property to activate the CPUs configured for the machine. The max_cpus limit of the machine should depend on the SoC definition but, unfortunately, these values are not available when the machine class is initialized. This is the reason why we add a check on num_cpus in the AspeedSoC realize handler. SMP support will be activated when models for such SoCs are implemented. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Message-id: 20190618165311.27066-6-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01hw/arm/aspeed: Add RTC to SoCJoel Stanley
All systems have an RTC. The IRQ is hooked up but the model does not use it at this stage. There is no guest code that uses it, so this limitation is acceptable. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20190618165311.27066-5-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01aspeed: add a per SoC mapping for the memory spaceCédric Le Goater
This will simplify the definition of new SoCs, like the AST2600 which should use a slightly different address space and have a different set of controllers. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Message-id: 20190618165311.27066-3-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01aspeed: add a per SoC mapping for the interrupt spaceCédric Le Goater
This will simplify the definition of new SoCs, like the AST2600 which should use a different CPU and a different IRQ number layout. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Message-id: 20190618165311.27066-2-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01i.mx7d: Add no-op/unimplemented PCIE PHY IP blockAndrey Smirnov
Add no-op/unimplemented PCIE PHY IP block. Needed by new kernels to use PCIE. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01i.mx7d: Add no-op/unimplemented APBH DMA moduleAndrey Smirnov
Instantiate no-op APBH DMA module. Needed to boot latest Linux kernel. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01hw/arm/virt: Add support for Cortex-A7Jan Kiszka
Allow cortex-a7 to be used with the virt board; it supports the v7VE features and there is no reason to deny this type. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: fc5404f7-4d1d-c28f-6e48-d8799c82acc0@web.de Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01hw/arm/msf2-som: Exit when the cpu is not the expected onePhilippe Mathieu-Daudé
This machine correctly defines its default_cpu_type to cortex-m3 and report an error if the user requested another cpu_type, however it does not exit, and this can confuse users trying to use another core: $ qemu-system-arm -M emcraft-sf2 -cpu cortex-m4 -kernel test-m4.elf qemu-system-arm: This board can only be used with CPU cortex-m3-arm-cpu [output related to M3 core ...] The CPU is indeed a M3 core: (qemu) info qom-tree /machine (emcraft-sf2-machine) /unattached (container) /device[0] (msf2-soc) /armv7m (armv7m) /cpu (cortex-m3-arm-cpu) Add the missing exit() call to return to the shell. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-id: 20190617160136.29930-1-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01hw/arm/boot: fix direct kernel boot with initrdAndrew Jones
Fix the condition used to check whether the initrd fits into RAM; in some cases if an initrd was also passed on the command line we would get an error stating that it was too big to fit into RAM after the kernel. Despite the error the loader continued anyway, though, so also add an exit(1) when the initrd is actually too big. Fixes: 852dc64d665f ("hw/arm/boot: Diagnose layouts that put initrd or DTB off the end of RAM") Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190618125844.4863-1-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-06-17hw/arm: Correctly disable FPU/DSP for some ARMSSE-based boardsPeter Maydell
The SSE-200 hardware has configurable integration settings which determine whether its two CPUs have the FPU and DSP: * CPU0_FPU (default 0) * CPU0_DSP (default 0) * CPU1_FPU (default 1) * CPU1_DSP (default 1) Similarly, the IoTKit has settings for its single CPU: * CPU0_FPU (default 1) * CPU0_DSP (default 1) Of our four boards that use either the IoTKit or the SSE-200: * mps2-an505, mps2-an521 and musca-a use the default settings * musca-b1 enables FPU and DSP on both CPUs Currently QEMU models all these boards using CPUs with both FPU and DSP enabled. This means that we are incorrect for mps2-an521 and musca-a, which should not have FPU or DSP on CPU0. Create QOM properties on the ARMSSE devices corresponding to the default h/w integration settings, and make the Musca-B1 board enable FPU and DSP on both CPUs. This fixes the mps2-an521 and musca-a behaviour, and leaves the musca-b1 and mps2-an505 behaviour unchanged. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20190517174046.11146-5-peter.maydell@linaro.org
2019-06-17hw/arm/armv7m: Forward "vfp" and "dsp" properties to CPUPeter Maydell
Create "vfp" and "dsp" properties on the armv7m container object which will be forwarded to its CPU object, so that SoCs can configure whether the CPU has these features. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20190517174046.11146-4-peter.maydell@linaro.org
2019-06-17hw/arm/boot: Honour image size field in AArch64 Image format kernelsPeter Maydell
Since Linux v3.17, the kernel's Image header includes a field image_size, which gives the total size of the kernel including unpopulated data sections such as the BSS). If this is present, then return it from load_aarch64_image() as the true size of the kernel rather than just using the size of the Image file itself. This allows the code which calculates where to put the initrd to avoid putting it in the kernel's BSS area. This means that we should be able to reliably load kernel images which are larger than 128MB without accidentally putting the initrd or dtb in locations that clash with the kernel itself. Fixes: https://bugs.launchpad.net/qemu/+bug/1823998 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190516144733.32399-5-peter.maydell@linaro.org
2019-06-17hw/arm/boot: Avoid placing the initrd on top of the kernelPeter Maydell
We currently put the initrd at the smaller of: * 128MB into RAM * halfway into the RAM (with the dtb following it). However for large kernels this might mean that the kernel overlaps the initrd. For some kinds of kernel (self-decompressing 32-bit kernels, and ELF images with a BSS section at the end) we don't know the exact size, but even there we have a minimum size. Put the initrd at least further into RAM than that. For image formats that can give us an exact kernel size, this will mean that we definitely avoid overlaying kernel and initrd. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190516144733.32399-4-peter.maydell@linaro.org
2019-06-17hw/arm/boot: Diagnose layouts that put initrd or DTB off the end of RAMPeter Maydell
We calculate the locations in memory where we want to put the initrd and the DTB based on the size of the kernel, since they come after it. Add some explicit checks that these aren't off the end of RAM entirely. (At the moment the way we calculate the initrd_start means that it can't ever be off the end of RAM, but that will change with the next commit.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190516144733.32399-3-peter.maydell@linaro.org
2019-06-17hw/arm/boot: Don't assume RAM starts at address zeroPeter Maydell
In the Arm kernel/initrd loading code, in some places we make the incorrect assumption that info->ram_size can be treated as the address of the end of RAM, as for instance when we calculate the available space for the initrd using "info->ram_size - info->initrd_start". This is wrong, because many Arm boards (including "virt") specify a non-zero info->loader_start to indicate that their RAM area starts at a non-zero physical address. Correct the places which make this incorrect assumption. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190516144733.32399-2-peter.maydell@linaro.org
2019-06-16hw/acpi: extract acpi_add_rom_blob()Wei Yang
arm and i386 has almost the same function acpi_add_rom_blob(), except giving different FWCfgCallback function. This patch moves acpi_add_rom_blob() to utils.c by passing FWCfgCallback to it. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> v7: * rebase on top of current master because of conflict v6: * change author from Igor to Michael v5: * remove unnecessary header glib/gprintf.h * rearrange include header to make it more suitable v4: * extract -> moves * adjust comment in source to make checkpatch happy v3: * put acpi_add_rom_blob() to hw/acpi/utils.c v2: * remove unused header in original source file Message-Id: <20190610011830.28398-1-richardw.yang@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-02-21 00:47:16 +0000