summary refs log tree commit diff stats
path: root/hw/arm/virt-acpi-build.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* qapi/acpi-hest: add an interface to do generic CPER error injectionMauro Carvalho Chehab2025-10-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Create a QMP command to be used for generic ACPI APEI hardware error injection (HEST) via GHESv2, and add support for it for ARM guests. Error injection uses ACPI_HEST_SRC_ID_QMP source ID to be platform independent. This is mapped at arch virt bindings, depending on the types supported by QEMU and by the BIOS. So, on ARM, this is supported via ACPI_GHES_NOTIFY_GPIO notification type. This patch was co-authored: - original ghes logic to inject a simple ARM record by Shiju Jose; - generic logic to handle block addresses by Jonathan Cameron; - generic GHESv2 error inject by Mauro Carvalho Chehab; Co-authored-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Co-authored-by: Shiju Jose <shiju.jose@huawei.com> Co-authored-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Shiju Jose <shiju.jose@huawei.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <81e2118b3c8b7e5da341817f277d61251655e0db.1758610789.git.mchehab+huawei@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* arm/virt: Wire up a GED error device for ACPI / GHESMauro Carvalho Chehab2025-10-051-0/+1
| | | | | | | | | | | | | | | | | | Adds support to ARM virtualization to allow handling generic error ACPI Event via GED & error source device. It is aligned with Linux Kernel patch: https://lore.kernel.org/lkml/1272350481-27951-8-git-send-email-ying.huang@intel.com/ Co-authored-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Co-authored-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <3237a76b1469d669436399495825348bf34122cd.1758610789.git.mchehab+huawei@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* acpi/generic_event_device: add logic to detect if HEST addr is availableMauro Carvalho Chehab2025-10-041-2/+16
| | | | | | | | | | | | | | Create a new property (x-has-hest-addr) and use it to detect if the GHES table offsets can be calculated from the HEST address (qemu 10.0 and upper) or via the legacy way via an offset obtained from the hardware_errors firmware file. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <c4eb3cf32a3f158ae62dac29e866ac3f373956c3.1758610789.git.mchehab+huawei@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* acpi/ghes: don't hard-code the number of sources for HEST tableMauro Carvalho Chehab2025-10-041-1/+7
| | | | | | | | | | | | | | | | | | | The current code is actually dependent on having just one error structure with a single source, as any change there would cause migration issues. As the number of sources should be arch-dependent, as it will depend on what kind of notifications will exist, and how many errors can be reported at the same time, change the logic to be more flexible, allowing the number of sources to be defined when building the HEST table by the caller. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <1698680848c11d6f26368426f1657e14faaf55c4.1758610789.git.mchehab+huawei@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* acpi/ghes: prepare to change the way HEST offsets are calculatedMauro Carvalho Chehab2025-10-041-3/+10
| | | | | | | | | | | | | | | | | | | | Add a new ags flag to change the way HEST offsets are calculated. Currently, offsets needed to store ACPI HEST offsets and read ack are calculated based on a previous knowledge from the logic which creates the HEST table. Such logic is not generic, not allowing to easily add more HEST entries nor replicates what OSPM does. As the next patches will be adding a more generic logic, add a new use_hest_addr, set to false, in preparation for such changes. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <f5de17bf04b27828e1a439ad396b4f7982eaf156.1758610789.git.mchehab+huawei@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* hw/arm/virt-acpi-build: Update IORT for multiple smmuv3 devicesShameer Kolothum2025-09-161-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the soon to be introduced user-creatable SMMUv3 devices for virt, it is possible to have multiple SMMUv3 devices associated with different PCIe root complexes. Update IORT nodes accordingly. An example IORT Id mappings for a Qemu virt machine with two PCIe Root Complexes each assocaited with a SMMUv3 will be something like below, -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.0 -device arm-smmuv3,primary-bus=pcie.1,id=smmuv3.1 ... +--------------------+ +--------------------+ | Root Complex 0 | | Root Complex 1 | | | | | | Requestor IDs | | Requestor IDs | | 0x0000 - 0x00FF | | 0x0100 - 0x01FF | +---------+----------+ +---------+----------+ | | | | | Stream ID Mapping | v v +--------------------+ +--------------------+ | SMMUv3 Node 0 | | SMMUv3 Node 1 | | | | | | Stream IDs 0x0000- | | Stream IDs 0x0100- | | 0x00FF mapped from | | 0x01FF mapped from | | RC0 Requestor IDs | | RC1 Requestor IDs | +--------------------+ +--------------------+ | | | | +----------------+---------------+ | |Device ID Mapping v +----------------------------+ | ITS Node 0 | | | | Device IDs: | | 0x0000 - 0x00FF (from RC0) | | 0x0100 - 0x01FF (from RC1) | | 0x0200 - 0xFFFF (No SMMU) | +----------------------------+ Tested-by: Nathan Chen <nathanc@nvidia.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Reviewed-by: Donald Dutile <ddutile@redhat.com> Message-id: 20250829082543.7680-4-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt-acpi-build: Re-arrange SMMUv3 IORT buildShameer Kolothum2025-09-161-45/+92
| | | | | | | | | | | | | | | | | | | | | Introduce a new struct AcpiIortSMMUv3Dev to hold all the information required for SMMUv3 IORT node and use that for populating the node. The current machine wide SMMUv3 is named as legacy SMMUv3 as we will soon add support for user-creatable SMMUv3 devices. These changes will be useful to have common code paths when we add that support. Tested-by: Nathan Chen <nathanc@nvidia.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Reviewed-by: Donald Dutile <ddutile@redhat.com> Message-id: 20250829082543.7680-3-skolothumtho@nvidia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt-acpi-build: Modify the DSDT ACPI table to enable ACPI PCI hotplugEric Auger2025-07-151-0/+17
| | | | | | | | | | | Modify the DSDT ACPI table to enable ACPI PCI hotplug. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20250714080639.2525563-24-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* hw/arm/virt-acpi-build: Let non hotplug ports support static acpi-indexEric Auger2025-07-151-0/+12
| | | | | | | | | | | | | | hw/arm/virt-acpi-build: Let non hotplug ports support static acpi-index Add the requested ACPI bits requested to support static acpi-index for non hotplug ports. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20250714080639.2525563-22-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* hw/pci-host/gpex-acpi: Use GED acpi pcihp propertyEric Auger2025-07-151-0/+9
| | | | | | | | | | | | Retrieve the acpi pcihp property value from the ged. In case this latter is not set, PCI native hotplug is used on pci0. For expander bridges we keep pci native hotplug, as done on x86 q35. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Message-Id: <20250714080639.2525563-8-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* acpi: Add machine option to disable SPCR tableLi Chen2025-07-141-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI SPCR (Serial Port Console Redirection) table allows firmware to specify a preferred serial console device to the operating system. On ARM64 systems, Linux by default respects this table: even if the kernel command line does not include a hardware serial console (e.g., "console=ttyAMA0"), the kernel still register the serial device referenced by SPCR as a printk console. While this behavior is standard-compliant, it can lead to situations where guest console behavior is influenced by platform firmware rather than user-specified configuration. To make guest console behavior more predictable and under user control, this patch introduces a machine option to explicitly disable SPCR table exposure: -machine spcr=off By default, the option is enabled (spcr=on), preserving existing behavior. When disabled, QEMU will omit the SPCR table from the guest's ACPI namespace, ensuring that only consoles explicitly declared in the kernel command line are registered. Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Message-Id: <20250528105404.457729-2-me@linux.beauty> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* hw/arm/virt-acpi-build: Don't create ITS id mappings by defaultShameer Kolothum2025-07-101-6/+0
| | | | | | | | | | | | | | | Commit d6afe18b7242 ("hw/arm/virt-acpi-build: Fix ACPI IORT and MADT tables when its=off") moved ITS group node generation under the its=on condition. However, it still creates rc_its_idmaps unconditionally, which results in duplicate ID mappings in the IORT table. Fixes:d6afe18b7242 ("hw/arm/virt-acpi-build: Fix ACPI IORT and MADT tables when its=off") Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Donald Dutile <ddutile@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt: Basic CXL enablement on pci_expander_bridge instances pxb-cxlJonathan Cameron2025-07-081-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Code based on i386/pc enablement. The memory layout places space for 16 host bridge register regions after the GIC_REDIST2 in the extended memmap. This is a hole in the current map so adding them here has no impact on placement of other memory regions (tested with enough CPUs for GIC_REDIST2 to be in use.) The high memory map is GiB aligned so the hole is there whatever the size of memory or device_memory below this point. The CFMWs are placed above the extended memmap. Note the existing variable highest_gpa is the highest GPA that has been allocated at a particular point in setting up the memory map. Whilst this caused some confusion in review there are existing comments explaining this so nothing is added. The cxl_devices_state.host_mr provides a small space in which to place the individual host bridge register regions for whatever host bridges are allocated via -device pxb-cxl on the command line. The existing dynamic sysbus infrastructure is not reused because pxb-cxl is a PCI device not a sysbus one but these registers are directly in the main memory map, not the PCI address space. Only create the CEDT table if cxl=on set for the machine. Default to off. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Tested-by: Itaru Kitayama <itaru.kitayama@fujitsu.com> Tested-by: Li Zhijian <lizhijian@fujitsu.com> Message-id: 20250703104110.992379-4-Jonathan.Cameron@huawei.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt-acpi-build: Fix ACPI IORT and MADT tables when its=offGustavo Romero2025-07-011-54/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the ITS Group nodes in the IORT table and the GIC ITS Struct in the MADT table are always generated, even if GIC ITS is not available on the machine. This commit fixes it by not generating the ITS Group nodes, not mapping any other node to them, and not advertising the GIC ITS in the MADT table, when GIC ITS is not available on the machine. Since the fix changes the MADT and IORT tables, add the blobs for the "its=off" test to the allow list and update them in the next commit. This commit also renames the smmu_idmaps and its_idmaps variables in build_iort() to rc_smmu_idmaps and rc_its_idmaps, respectively, to make it clearer which nodes are involved in the mappings associated with these variables. Reported-by: Udo Steinberg <udo@hypervisor.org> Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Message-id: 20250628195722.977078-9-gustavo.romero@linaro.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2886 Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Co-authored-by: Philippe Mathieu-Daudé <philmd@linaro.org> [PMM: wrapped an overlong comment] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt-acpi-build: Factor out create_its_idmapsGustavo Romero2025-07-011-21/+40
| | | | | | | | | | | | | Factor out a new function, create_its_idmaps(), from the current build_iort code. Add proper comments to it clarifying how the ID ranges that go directly to the ITS Group node are computed based on the ones that are directed to the SMMU node. Suggested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Message-id: 20250628195722.977078-6-gustavo.romero@linaro.org [PMM: drop hardcoded tabs] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt-acpi-build: Improve comment in build_iortGustavo Romero2025-07-011-6/+19
| | | | | | | | | | | | | | When building the Root Complex table, the comment about the code that maps the RC node to SMMU node is misleading because it reads "RC -> SMMUv3 -> ITS", but the code is only mapping the RCs IDs to the SMMUv3 node. The step of mapping from the SMMUv3 IDs to the ITS Group node is actually defined in another table (in the SMMUv3 node). So change the comment to read "RC -> SMMUv3" instead. Signed-off-by Gustavo Romero <gustavo.romero@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20250628195722.977078-5-gustavo.romero@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/intc/gicv3_its: Do not check its_class_name()Philippe Mathieu-Daudé2025-07-011-18/+14
| | | | | | | | | | | | | | | Since commit cc5e719e2c8 ("kvm: require KVM_CAP_SIGNAL_MSI"), the single implementation of its_class_name() no longer returns NULL (it now always returns a valid char pointer). Hence, update the prototype docstring and remove the tautological checks that use the its_class_name() returned value. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20250628195722.977078-2-gustavo.romero@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt: Remove VirtMachineClass::claim_edge_triggered_timers fieldPhilippe Mathieu-Daudé2025-05-061-4/+1
| | | | | | | | | | | The VirtMachineClass::claim_edge_triggered_timers field was only used by virt-2.8 machine, which got removed. Remove it and simplify fdt_add_timer_nodes() and build_gtdt(). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt: Remove VirtMachineClass::no_its fieldPhilippe Mathieu-Daudé2025-05-061-3/+2
| | | | | | | | | | | The VirtMachineClass::no_its field was only used by virt-2.7 machine, which got removed. Remove it and simplify virt_instance_init() and virt_acpi_build(). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* acpi/ghes: simplify the per-arch caller to build HEST tableMauro Carvalho Chehab2025-01-151-3/+2
| | | | | | | | | | | | | | | | | | The GHES driver requires not only a HEST table, but also a separate firmware file to store Error Structure records. It can't do one without the other. Simplify the caller logic for it to require one function. No functional changes. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <9584bb8953385e165681d5d185c503f8df8ef42f.1736945236.git.mchehab+huawei@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* Merge tag 'exec-20241220' of https://github.com/philmd/qemu into stagingStefan Hajnoczi2024-12-211-3/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Accel & Exec patch queue - Ignore writes to CNTP_CTL_EL0 on HVF ARM (Alexander) - Add '-d invalid_mem' logging option (Zoltan) - Create QOM containers explicitly (Peter) - Rename sysemu/ -> system/ (Philippe) - Re-orderning of include/exec/ headers (Philippe) Move a lot of declarations from these legacy mixed bag headers: . "exec/cpu-all.h" . "exec/cpu-common.h" . "exec/cpu-defs.h" . "exec/exec-all.h" . "exec/translate-all" to these more specific ones: . "exec/page-protection.h" . "exec/translation-block.h" . "user/cpu_loop.h" . "user/guest-host.h" . "user/page-protection.h" # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmdlnyAACgkQ4+MsLN6t # wN6mBw//QFWi7CrU+bb8KMM53kOU9C507tjn99LLGFb5or73/umDsw6eo/b8DHBt # KIwGLgATel42oojKfNKavtAzLK5rOrywpboPDpa3SNeF1onW+99NGJ52LQUqIX6K # A6bS0fPdGG9ZzEuPpbjDXlp++0yhDcdSgZsS42fEsT7Dyj5gzJYlqpqhiXGqpsn8 # 4Y0UMxSL21K3HEexlzw2hsoOBFA3tUm2ujNDhNkt8QASr85yQVLCypABJnuoe/// # 5Ojl5wTBeDwhANET0rhwHK8eIYaNboiM9fHopJYhvyw1bz6yAu9jQwzF/MrL3s/r # xa4OBHBy5mq2hQV9Shcl3UfCQdk/vDaYaWpgzJGX8stgMGYfnfej1SIl8haJIfcl # VMX8/jEFdYbjhO4AeGRYcBzWjEJymkDJZoiSWp2NuEDi6jqIW+7yW1q0Rnlg9lay # ShAqLK5Pv4zUw3t0Jy3qv9KSW8sbs6PQxtzXjk8p97rTf76BJ2pF8sv1tVzmsidP # 9L92Hv5O34IqzBu2oATOUZYJk89YGmTIUSLkpT7asJZpBLwNM2qLp5jO00WVU0Sd # +kAn324guYPkko/TVnjC/AY7CMu55EOtD9NU35k3mUAnxXT9oDUeL4NlYtfgrJx6 # x1Nzr2FkS68+wlPAFKNSSU5lTjsjNaFM0bIJ4LCNtenJVP+SnRo= # =cjz8 # -----END PGP SIGNATURE----- # gpg: Signature made Fri 20 Dec 2024 11:45:20 EST # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * tag 'exec-20241220' of https://github.com/philmd/qemu: (59 commits) util/qemu-timer: fix indentation meson: Do not define CONFIG_DEVICES on user emulation system/accel-ops: Remove unnecessary 'exec/cpu-common.h' header system/numa: Remove unnecessary 'exec/cpu-common.h' header hw/xen: Remove unnecessary 'exec/cpu-common.h' header target/mips: Drop left-over comment about Jazz machine target/mips: Remove tswap() calls in semihosting uhi_fstat_cb() target/xtensa: Remove tswap() calls in semihosting simcall() helper accel/tcg: Un-inline translator_is_same_page() accel/tcg: Include missing 'exec/translation-block.h' header accel/tcg: Move tcg_cflags_has/set() to 'exec/translation-block.h' accel/tcg: Restrict curr_cflags() declaration to 'internal-common.h' qemu/coroutine: Include missing 'qemu/atomic.h' header exec/translation-block: Include missing 'qemu/atomic.h' header accel/tcg: Declare cpu_loop_exit_requested() in 'exec/cpu-common.h' exec/cpu-all: Include 'cpu.h' earlier so MMU_USER_IDX is always defined target/sparc: Move sparc_restore_state_to_opc() to cpu.c target/sparc: Uninline cpu_get_tb_cpu_state() target/loongarch: Declare loongarch_cpu_dump_state() locally user: Move various declarations out of 'exec/exec-all.h' ... Conflicts: hw/char/riscv_htif.c hw/intc/riscv_aplic.c target/s390x/cpu.c Apply sysemu header path changes to not in the pull request. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
| * include: Rename sysemu/ -> system/Philippe Mathieu-Daudé2024-12-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Headers in include/sysemu/ are not only related to system *emulation*, they are also used by virtualization. Rename as system/ which is clearer. Files renamed manually then mechanical change using sed tool. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Lei Yang <leiyang@redhat.com> Message-Id: <20241203172445.28576-1-philmd@linaro.org>
* | hw/acpi: Upgrade ACPI SPCR table to support SPCR table revision 4 formatSia Jee Heng2024-12-201-2/+6
|/ | | | | | | | | | | | | | | | Update the SPCR table to accommodate the SPCR Table revision 4 [1]. The SPCR table has been modified to adhere to the revision 4 format [2]. [1]: https://learn.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table [2]: https://github.com/acpica/acpica/pull/931 Signed-off-by: Sia Jee Heng <jeeheng.sia@starfivetech.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Message-ID: <20241028015744.624943-3-jeeheng.sia@starfivetech.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* hw/acpi: Generic Port Affinity Structure supportJonathan Cameron2024-11-041-1/+1
| | | | | | | | | | | | | | | | | | | | These are very similar to the recently added Generic Initiators but instead of representing an initiator of memory traffic they represent an edge point beyond which may lie either targets or initiators. Here we add these ports such that they may be targets of hmat_lb records to describe the latency and bandwidth from host side initiators to the port. A discoverable mechanism such as UEFI CDAT read from CXL devices and switches is used to discover the remainder of the path, and the OS can build up full latency and bandwidth numbers as need for work and data placement decisions. Acked-by: Markus Armbruster <armbru@redhat.com> Tested-by: "Huang, Ying" <ying.huang@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20240916174122.1843197-1-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* acpi/pci: Move Generic Initiator object handling into acpi/pci.*Jonathan Cameron2024-11-041-1/+0
| | | | | | | | | | | | | | | | | | | Whilst ACPI SRAT Generic Initiator Afinity Structures are able to refer to both PCI and ACPI Device Handles, the QEMU implementation only implements the PCI Device Handle case. For now move the code into the existing hw/acpi/pci.c file and header. If support for ACPI Device Handles is added in the future, perhaps this will be moved again. Also push the struct AcpiGenericInitiator down into the c file as not used outside pci.c. Suggested-by: Igor Mammedov <imammedo@redhat.com> Tested-by: "Huang, Ying" <ying.huang@intel.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20240916171017.1841767-7-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* arm/virt: place power button pin number on a defineMauro Carvalho Chehab2024-08-121-3/+3
| | | | | | | | | | | | | | | | | | Having magic numbers inside the code is not a good idea, as it is error-prone. So, instead, create a macro with the number definition. Link: https://lore.kernel.org/qemu-devel/CAFEAcA-PYnZ-32MRX+PgvzhnoAV80zBKMYg61j2f=oHaGfwSsg@mail.gmail.com/ Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: ef0e7f5fca6cd94eda415ecee670c3028c671b74.1723121692.git.mchehab+huawei@kernel.org Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt-acpi-build: Fix id_count in build_iort_id_mappingNicolin Chen2024-07-031-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | It's observed that Linux kernel booting with the VM reports a "conflicting mapping for input ID" FW_BUG. The IORT doc defines "Number of IDs" to be "the number of IDs in the range minus one", while virt-acpi-build.c simply stores the number of IDs in the id_count without the "minus one". Meanwhile, some of the callers pass in a 0xFFFF following the spec. So, this is a mismatch between the function and its callers. Fix build_iort_id_mapping() by internally subtracting one from the pass-in @id_count. Accordingly make sure that all existing callers pass in a value without the "minus one", i.e. change all 0xFFFFs to 0x10000s. Also, add a few lines of comments to highlight this change along with the referencing document for this build_iort_id_mapping(). Fixes: 42e0f050e3a5 ("hw/arm/virt-acpi-build: Add IORT support to bypass SMMUv3") Suggested-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Message-Id: <20240619201243.936819-1-nicolinc@nvidia.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* hw/arm/virt-acpi-build: Drop local iort_node_offsetNicolin Chen2024-07-031-2/+1
| | | | | | | | | | | | | | | | Both the other two callers of build_iort_id_mapping() just directly pass in the IORT_NODE_OFFSET macro. Keeping a "const uint32_t" local variable storing the same value doesn't have any gain. Simplify this by replacing the only place using this local variable with the macro directly. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Message-Id: <20240619001708.926511-1-nicolinc@nvidia.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* hw/arm/virt: allow creation of a second NonSecure UARTPeter Maydell2024-06-211-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | For some use-cases, it is helpful to have more than one UART available to the guest. If the second UART slot is not already used for a TrustZone Secure-World-only UART, create it as a NonSecure UART only when the user provides a serial backend (e.g. via a second -serial command line option). This avoids problems where existing guest software only expects a single UART, and gets confused by the second UART in the DTB. The major example of this is older EDK2 firmware, which will send the GRUB bootloader output to UART1 and the guest serial output to UART0. Users who want to use both UARTs with a guest setup including EDK2 are advised to update to EDK2 release edk2-stable202311 or newer. (The prebuilt EDK2 blobs QEMU upstream provides are new enough.) The relevant EDK2 changes are the ones described here: https://bugzilla.tianocore.org/show_bug.cgi?id=4577 Inspired-by: Axel Heider <axel.heider@hensoldt.net> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240610162343.2131524-4-peter.maydell@linaro.org
* hw/arm/virt: Rename VIRT_UART and VIRT_SECURE_UART to VIRT_UART[01]Peter Maydell2024-06-211-6/+6
| | | | | | | | | | We're going to make the second UART not always a secure-only device. Rename the constants VIRT_UART and VIRT_SECURE_UART to VIRT_UART0 and VIRT_UART1 accordingly. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240610162343.2131524-3-peter.maydell@linaro.org
* hw/acpi: Implement the SRAT GI affinity structureAnkit Agrawal2024-03-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI spec provides a scheme to associate "Generic Initiators" [1] (e.g. heterogeneous processors and accelerators, GPUs, and I/O devices with integrated compute or DMA engines GPUs) with Proximity Domains. This is achieved using Generic Initiator Affinity Structure in SRAT. During bootup, Linux kernel parse the ACPI SRAT to determine the PXM ids and create a NUMA node for each unique PXM ID encountered. Qemu currently do not implement these structures while building SRAT. Add GI structures while building VM ACPI SRAT. The association between device and node are stored using acpi-generic-initiator object. Lookup presence of all such objects and use them to build these structures. The structure needs a PCI device handle [2] that consists of the device BDF. The vfio-pci device corresponding to the acpi-generic-initiator object is located to determine the BDF. [1] ACPI Spec 6.3, Section 5.2.16.6 [2] ACPI Spec 6.3, Table 5.80 Cc: Jonathan Cameron <qemu-devel@nongnu.org> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cedric Le Goater <clg@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Message-Id: <20240308145525.10886-3-ankita@nvidia.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* hw/arm/virt-acpi-build.c: Migrate SPCR creation to common locationSia Jee Heng2024-03-081-41/+27
| | | | | | | | | | | | | | RISC-V should also generate the SPCR in a manner similar to ARM. Therefore, instead of replicating the code, relocate this function to the common AML build. Signed-off-by: Sia Jee Heng <jeeheng.sia@starfivetech.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240129021440.17640-2-jeeheng.sia@starfivetech.com> [ Changes by AF: - Add missing Language SPCR entry ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* hw/arm/virt: Wire up non-secure EL2 virtual timer IRQPeter Maydell2024-02-151-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Armv8.1+ CPUs have the Virtual Host Extension (VHE) which adds a non-secure EL2 virtual timer. We implemented the timer itself in the CPU model, but never wired up its IRQ line to the GIC. Wire up the IRQ line (this is always safe whether the CPU has the interrupt or not, since it always creates the outbound IRQ line). Report it to the guest via dtb and ACPI if the CPU has the feature. The DTB binding is documented in the kernel's Documentation/devicetree/bindings/timer/arm\,arch_timer.yaml and the ACPI table entries are documented in the ACPI specification version 6.3 or later. Because the IRQ line ACPI binding is new in 6.3, we need to bump the FADT table rev to show that we might be using 6.3 features. Note that exposing this IRQ in the DTB will trigger a bug in EDK2 versions prior to edk2-stable202311, for users who use the virt board with 'virtualization=on' to enable EL2 emulation and are booting an EDK2 guest BIOS, if that EDK2 has assertions enabled. The effect is that EDK2 will assert on bootup: ASSERT [ArmTimerDxe] /home/kraxel/projects/qemu/roms/edk2/ArmVirtPkg/Library/ArmVirtTimerFdtClientLib/ArmVirtTimerFdtClientLib.c(72): PropSize == 36 || PropSize == 48 If you see that assertion you should do one of: * update your EDK2 binaries to edk2-stable202311 or newer * use the 'virt-8.2' versioned machine type * not use 'virtualization=on' (The versions shipped with QEMU itself have the fix.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Message-id: 20240122143537.233498-3-peter.maydell@linaro.org
* hw/arm: Add `\n` to hint messageGreg Kurz2024-01-301-1/+1
| | | | | | | | error_printf() doesn't add newlines. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Ani Sinha <anisinha@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
* hw/arm: Build various units only oncePhilippe Mathieu-Daudé2024-01-261-1/+0
| | | | | | | | | | | | Various files in hw/arm/ don't require "cpu.h" anymore. Except virt-acpi-build.c, all of them don't require any ARM specific knowledge anymore and can be build once as target agnostic units. Update meson accordingly. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240118200643.29037-21-philmd@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Expose arm_cpu_mp_affinity() in 'multiprocessing.h' headerPhilippe Mathieu-Daudé2024-01-261-0/+1
| | | | | | | | | | | | | | | | Declare arm_cpu_mp_affinity() prototype in the new "target/arm/multiprocessing.h" header so units in hw/arm/ can use it without having to include the huge target-specific "cpu.h". File list to include the new header generated using: $ git grep -lw arm_cpu_mp_affinity Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240118200643.29037-11-philmd@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* target/arm: Create arm_cpu_mp_affinityRichard Henderson2024-01-261-1/+1
| | | | | | | | | | Wrapper to return the mp affinity bits from the cpu. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240118200643.29037-10-philmd@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt-acpi-build.c: Migrate virtio creation to common locationSunil V L2024-01-101-28/+4
| | | | | | | | | | | | | | RISC-V also needs to create the virtio in DSDT in the same way as ARM. So, instead of duplicating the code, move this function to the device specific file which is common across architectures. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-3-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* hw/arm/virt-acpi-build.c: Migrate fw_cfg creation to common locationSunil V L2024-01-101-17/+2
| | | | | | | | | | | | | | | RISC-V also needs to use the same code to create fw_cfg in DSDT. So, avoid code duplication by moving the code in arm and riscv to a device specific file. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-2-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
* hw/arm: Constify VMStateRichard Henderson2023-12-291-1/+1
| | | | | | | Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231221031652.119827-19-richard.henderson@linaro.org>
* hw/arm/virt: Report correct register sizes in ACPI DBG2/SPCR tables.Udo Steinberg2023-11-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Documentation for using the GAS in ACPI tables to report debug UART addresses at https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table states the following: - The Register Bit Width field contains the register stride and must be a power of 2 that is at least as large as the access size. On 32-bit platforms this value cannot exceed 32. On 64-bit platforms this value cannot exceed 64. - The Access Size field is used to determine whether byte, WORD, DWORD, or QWORD accesses are to be used. QWORD accesses are only valid on 64-bit architectures. Documentation for the ARM PL011 at https://developer.arm.com/documentation/ddi0183/latest/ states that the registers are: - spaced 4 bytes apart (see Table 3-2), so register stride must be 32. - 16 bits in size in some cases (see individual registers), so access size must be at least 2. Linux doesn't seem to care about this error in the table, but it does affect at least the NOVA microhypervisor. In theory we therefore have a choice between reporting the access size as 2 (16 bit accesses) or 3 (32-bit accesses). In practice, Linux does not correctly handle the case where the table reports the access size as 2: as of kernel commit 750b95887e5678, the code in acpi_parse_spcr() tries to tell the serial driver to use 16 bit accesses by passing "mmio16" in the option string, but the PL011 driver code in pl011_console_match() only recognizes "mmio" or "mmio32". The result is that unless the user has enabled 'earlycon' there is no console output from the guest kernel. We therefore choose to report the access size as 32 bits; this works for NOVA and also for Linux. It is also what the UEFI firmware on a Raspberry Pi 4 reports, so we're in line with existing real-world practice. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1938 Signed-off-by: Udo Steinberg <udo@hypervisor.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: minor commit message tweaks; use 32 bit accesses] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* {include/}hw/arm: refactor virt PPI logicLeif Lindholm2023-10-191-6/+6
| | | | | | | | | | | | | | | | | | | | GIC Private Peripheral Interrupts (PPI) are defined as GIC INTID 16-31. As in, PPI0 is INTID16 .. PPI15 is INTID31. Arm's Base System Architecture specification (BSA) lists the mandated and recommended private interrupt IDs by INTID, not by PPI index. But current definitions in virt define them by PPI index, complicating cross referencing. Meanwhile, the PPI(x) macro counterintuitively adds 16 to the input value, converting a PPI index to an INTID. Resolve this by redefining the BSA-allocated PPIs by their INTIDs, and replacing the PPI(x) macro with an INTID_TO_PPI(x) one where required. Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com> Message-id: 20230919090229.188092-2-quic_llindhol@quicinc.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt-acpi-build.c: Add missing headerPeng Liang2023-07-081-0/+1
| | | | | | | | | | | | | | | | | virt-acpi-build.c uses warn_report. However, it doesn't include qemu/error-report.h directly, it include qemu/error-report.h via trace.h if we enable log trace backend. But if we disable the log trace backend (e.g., --enable-trace-backends=nop), then virt-acpi-build.c will not include qemu/error-report.h any more and it will lead to build errors. Include qemu/error-report.h directly in virt-acpi-build.c to avoid the errors. Fixes: 451b157041 ("acpi: Align the size to 128k") Signed-off-by: Peng Liang <tcx4c70@gmail.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (mjt: move the #include higher as suggested by Ani Sinha)
* hw/intc/arm_gic: Un-inline GIC*/ITS class_name() helpersPhilippe Mathieu-Daudé2023-06-281-1/+1
| | | | | | | | | | | | | | "kvm_arm.h" contains external and internal prototype declarations. Files under the hw/ directory should only access the KVM external API. In order to avoid machine / device models to include "kvm_arm.h" simply to get the QOM GIC/ITS class name, un-inline each class name getter to the proper device model file. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230405160454.97436-4-philmd@linaro.org>
* hw/arm: Fix some typos in comments (most found by codespell)Stefan Weil2023-04-201-1/+1
| | | | | | | Signed-off-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20230409200526.1156456-1-sw@weilnetz.de Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* hw/arm/virt: Enable HMAT on arm virt machineXiang Chen2022-11-071-0/+7
| | | | | | | | | | | | | Since the patchset ("Build ACPI Heterogeneous Memory Attribute Table (HMAT)"), HMAT is supported, but only x86 is enabled. Enable HMAT on arm virt machine. Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: Hesham Almatary <hesham.almatary@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20221027100037.251-7-hesham.almatary@huawei.com> Tested-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* acpi: arm/virt: madt: bump to revision 4 accordingly to ACPI 6.0 Errata AMiguel Luis2022-11-071-9/+7
| | | | | | | | | | | | | MADT has been updated with the GIC Structures from ACPI 6.0 Errata A and so MADT revision and GICC Structure must be updated also. Fixes: 37f33084ed2e ("acpi: arm/virt: madt: use build_append_int_noprefix() API to compose MADT table") Signed-off-by: Miguel Luis <miguel.luis@oracle.com> Reviewed-by: Ani Sinha <ani@anisinha.ca> Message-Id: <20221011181730.10885-4-miguel.luis@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* acpi: fadt: support revision 6.0 of the ACPI specificationMiguel Luis2022-11-071-5/+5
| | | | | | | | | | | | | | | | | | | | | Update the Fixed ACPI Description Table (FADT) to revision 6.0 of the ACPI specification adding the field "Hypervisor Vendor Identity". This field's description states the following: "64-bit identifier of hypervisor vendor. All bytes in this field are considered part of the vendor identity. These identifiers are defined independently by the vendors themselves, usually following the name of the hypervisor product. Version information should NOT be included in this field - this shall simply denote the vendor's name or identifier. Version information can be communicated through a supplemental vendor-specific hypervisor API. Firmware implementers would place zero bytes into this field, denoting that no hypervisor is present in the actual firmware." Signed-off-by: Miguel Luis <miguel.luis@oracle.com> Reviewed-by: Ani Sinha <ani@anisinha.ca> Message-Id: <20221011181730.10885-3-miguel.luis@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* acpi: arm/virt: build_gtdt: fix invalid 64-bit physical addressesMiguel Luis2022-10-091-3/+2
| | | | | | | | | | | | | | Per the ACPI 6.5 specification, on the GTDT Table Structure, the Counter Control Block Address and Counter Read Block Address fields of the GTDT table should be set to 0xFFFFFFFFFFFFFFFF if not provided, rather than 0x0. Fixes: 41041e57085 ("acpi: arm/virt: build_gtdt: use acpi_table_begin()/acpi_table_end() instead of build_header()") Signed-off-by: Miguel Luis <miguel.luis@oracle.com> Message-Id: <20220920162137.75239-3-miguel.luis@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Ani Sinha <ani@anisinha.ca>
* hw/arm/virt-acpi-build: Present the GICR structure properly for GICv4Zenghui Yu2022-08-121-2/+2
| | | | | | | | | | | | | | | | With the introduction of the new TCG GICv4, build_madt() is badly broken as we do not present any GIC Redistributor structure in MADT for GICv4 guests, so that they have no idea about where the Redistributor register frames are. This fixes a Linux guest crash at boot time with ACPI enabled and '-machine gic-version=4'. While at it, let's convert the remaining hard coded gic_version into enumeration VIRT_GIC_VERSION_2 for consistency. Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Message-id: 20220812022018.1069-1-yuzenghui@huawei.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>