aboutsummaryrefslogtreecommitdiff
path: root/include/hw
AgeCommit message (Collapse)Author
2024-07-02hw: skip registration of outdated versioned machine typesDaniel P. Berrangé
This calls the MACHINE_VER_DELETION() macro in the machine type registration method, so that when a versioned machine type reaches the end of its life, it is no longer registered with QOM and thus cannot be used. The actual definition of the machine type should be deleted at this point, but experience shows that can easily be forgotten. By skipping registration the manual code deletion task can be done at any later date. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240620165742.1711389-12-berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-02hw: set deprecation info for all versioned machine typesDaniel P. Berrangé
This calls the MACHINE_VER_DEPRECATION() macro in the definition of all machine type classes which support versioning. This ensures that they will automatically get deprecation info set when they reach the appropriate point in their lifecycle. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240620165742.1711389-11-berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-02include/hw: temporarily disable deletion of versioned machine typesDaniel P. Berrangé
The new deprecation and deletion policy for versioned machine types is being introduced in QEMU 9.1.0. Under the new policy a number of old machine types (any prior to 2.12) would be liable for immediate deletion which would be a violation of our historical deprecation and removal policy Thus automatic deletions (by skipping QOM registration) are temporarily gated on existance of the env variable "QEMU_DELETE_MACHINES" / QEMU version number >= 10.1.0. This allows opt-in testing of the automatic deletion logic, while activating it fully in QEMU >= 10.1.0. This whole commit should be reverted in the 10.1.0 dev cycle or shortly thereafter. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20240620165742.1711389-10-berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-02include/hw: add macros for deprecation & removal of versioned machinesDaniel P. Berrangé
Versioned machines live for a long time to provide back compat for incoming migration and restore of saved images. To guide users away from usage of old machines, however, we want to deprecate any older than 3 years (equiv of 9 releases), and delete any older than 6 years (equiva of 18 releases). To get a standardized deprecation message and avoid having to remember to manually add it after three years, this introduces two macros to be used by targets when defining versioned machines. * MACHINE_VER_DEPRECATION(major, minor) Automates the task of setting the 'deprecation_reason' field on the machine, if-and-only-if the major/minor version is older than 3 years. * MACHINE_VER_DELETION(major, minor) Simulates the deletion of by skipping registration of the QOM type for a versioned machine, if-and-only-if the major/minor version is older than 6 years. By using these two macros there is no longer any manual work required per-release to deprecate old machines. By preventing the use of machines that have reached their deletion date, it is also not necessary to manually delete machines per-release. Deletion can be batched up once a year or whenever makes most sense. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240620165742.1711389-9-berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-02hw/i386: convert 'i440fx' machine definitions to use new macrosDaniel P. Berrangé
This changes the DEFINE_I440FX_MACHINE macro to use the common helpers for constructing versioned symbol names and strings, bringing greater consistency across targets. The added benefit is that it avoids the need to repeat the version number thrice in three different formats in the calls to DEFINE_I440FX_MACHINE. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240620165742.1711389-7-berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-02include/hw: add helpers for defining versioned machine typesDaniel P. Berrangé
The various targets which define versioned machine types have a bunch of obfuscated macro code for defining unique function and variable names using string concatenation. This adds a couple of helpers to improve the clarity of such code macro. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20240620165742.1711389-2-berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-01virtio-pci: implement No_Soft_Reset bitJiqian Chen
In current code, when guest does S3, virtio-gpu are reset due to the bit No_Soft_Reset is not set. After resetting, the display resources of virtio-gpu are destroyed, then the display can't come back and only show blank after resuming. Implement No_Soft_Reset bit of PCI_PM_CTRL register, then guest can check this bit, if this bit is set, the devices resetting will not be done, and then the display can work after resuming. No_Soft_Reset bit is implemented for all virtio devices, and was tested only on virtio-gpu device. Set it false by default for safety. Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com> Message-Id: <20240606102205.114671-3-Jiqian.Chen@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01hw/misc/pvpanic: add support for normal shutdownsThomas Weißschuh
Shutdown requests are normally hardware dependent. By extending pvpanic to also handle shutdown requests, guests can submit such requests with an easily implementable and cross-platform mechanism. Acked-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de> Message-Id: <20240527-pvpanic-shutdown-v8-5-5a28ec02558b@t-8ch.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01hw/misc/pvpanic: centralize definition of supported eventsThomas Weißschuh
The different components of pvpanic duplicate the list of supported events. Move it to the shared header file to minimize changes when new events are added. MST: tweak: keep header included in pvpanic.c to avoid header dependency, rebase. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de> Message-Id: <20240527-pvpanic-shutdown-v8-3-5a28ec02558b@t-8ch.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01hw/mem/cxl_type3: Add DPA range validation for accesses to DC regionsFan Ni
All DPA ranges in the DC regions are invalid to access until an extent covering the range has been successfully accepted by the host. A bitmap is added to each region to record whether a DC block in the region has been backed by a DC extent. Each bit in the bitmap represents a DC block. When a DC extent is accepted, all the bits representing the blocks in the extent are set, which will be cleared when the extent is released. Tested-by: Svetly Todorov <svetly.todorov@memverge.com> Reviewed-by: Gregory Price <gregory.price@memverge.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Fan Ni <fan.ni@samsung.com> Message-Id: <20240523174651.1089554-13-nifan.cxl@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01hw/cxl/events: Add qmp interfaces to add/release dynamic capacity extentsFan Ni
To simulate FM functionalities for initiating Dynamic Capacity Add (Opcode 5604h) and Dynamic Capacity Release (Opcode 5605h) as in CXL spec r3.1 7.6.7.6.5 and 7.6.7.6.6, we implemented two QMP interfaces to issue add/release dynamic capacity extents requests. With the change, we allow to release an extent only when its DPA range is contained by a single accepted extent in the device. That is to say, extent superset release is not supported yet. 1. Add dynamic capacity extents: For example, the command to add two continuous extents (each 128MiB long) to region 0 (starting at DPA offset 0) looks like below: { "execute": "qmp_capabilities" } { "execute": "cxl-add-dynamic-capacity", "arguments": { "path": "/machine/peripheral/cxl-dcd0", "host-id": 0, "selection-policy": "prescriptive", "region": 0, "extents": [ { "offset": 0, "len": 134217728 }, { "offset": 134217728, "len": 134217728 } ] } } 2. Release dynamic capacity extents: For example, the command to release an extent of size 128MiB from region 0 (DPA offset 128MiB) looks like below: { "execute": "cxl-release-dynamic-capacity", "arguments": { "path": "/machine/peripheral/cxl-dcd0", "host-id": 0, "removal-policy":"prescriptive", "region": 0, "extents": [ { "offset": 134217728, "len": 134217728 } ] } } Tested-by: Svetly Todorov <svetly.todorov@memverge.com> Reviewed-by: Gregory Price <gregory.price@memverge.com> Signed-off-by: Fan Ni <fan.ni@samsung.com> Message-Id: <20240523174651.1089554-12-nifan.cxl@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01hw/cxl/cxl-mailbox-utils: Add mailbox commands to support add/release ↵Fan Ni
dynamic capacity response Per CXL spec 3.1, two mailbox commands are implemented: Add Dynamic Capacity Response (Opcode 4802h) 8.2.9.9.9.3, and Release Dynamic Capacity (Opcode 4803h) 8.2.9.9.9.4. For the process of the above two commands, we use two-pass approach. Pass 1: Check whether the input payload is valid or not; if not, skip Pass 2 and return mailbox process error. Pass 2: Do the real work--add or release extents, respectively. Tested-by: Svetly Todorov <svetly.todorov@memverge.com> Reviewed-by: Gregory Price <gregory.price@memverge.com> Signed-off-by: Fan Ni <fan.ni@samsung.com> Message-Id: <20240523174651.1089554-11-nifan.cxl@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01hw/mem/cxl_type3: Add DC extent list representative and get DC extent list ↵Fan Ni
mailbox support Add dynamic capacity extent list representative to the definition of CXLType3Dev and implement get DC extent list mailbox command per CXL.spec.3.1:.8.2.9.9.9.2. Tested-by: Svetly Todorov <svetly.todorov@memverge.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Fan Ni <fan.ni@samsung.com> Message-Id: <20240523174651.1089554-10-nifan.cxl@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01hw/mem/cxl_type3: Add host backend and address space handling for DC regionsFan Ni
Add (file/memory backed) host backend for DCD. All the dynamic capacity regions will share a single, large enough host backend. Set up address space for DC regions to support read/write operations to dynamic capacity for DCD. With the change, the following support is added: 1. Add a new property to type3 device "volatile-dc-memdev" to point to host memory backend for dynamic capacity. Currently, all DC regions share one host backend; 2. Add namespace for dynamic capacity for read/write support; 3. Create cdat entries for each dynamic capacity region. Reviewed-by: Gregory Price <gregory.price@memverge.com> Signed-off-by: Fan Ni <fan.ni@samsung.com> Message-Id: <20240523174651.1089554-9-nifan.cxl@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01include/hw/cxl/cxl_device: Rename mem_size as static_mem_size for type3 ↵Fan Ni
memory devices Rename mem_size as static_mem_size for type3 memdev to cover static RAM and pmem capacity, preparing for the introduction of dynamic capacity to support dynamic capacity devices. Reviewed-by: Gregory Price <gregory.price@memverge.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Fan Ni <fan.ni@samsung.com> Message-Id: <20240523174651.1089554-6-nifan.cxl@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01hw/cxl/cxl-mailbox-utils: Add dynamic capacity region representative and ↵Fan Ni
mailbox command support Per cxl spec r3.1, add dynamic capacity (DC) region representative based on Table 8-165 and extend the cxl type3 device definition to include DC region information. Also, based on info in 8.2.9.9.9.1, add 'Get Dynamic Capacity Configuration' mailbox support. Note: we store region decode length as byte-wise length on the device, which should be divided by 256 * MiB before being returned to the host for "Get Dynamic Capacity Configuration" mailbox command per specification. Reviewed-by: Gregory Price <gregory.price@memverge.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Fan Ni <fan.ni@samsung.com> Message-Id: <20240523174651.1089554-5-nifan.cxl@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01hw/cxl/mailbox: interface to add CCI commands to an existing CCIGregory Price
This enables wrapper devices to customize the base device's CCI (for example, with custom commands outside the specification) without the need to change the base device. The also enabled the base device to dispatch those commands without requiring additional driver support. Heavily edited by Jonathan Cameron to increase code reuse Signed-off-by: Gregory Price <gregory.price@memverge.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Fan Ni <fan.ni@samsung.com> Message-Id: <20240523174651.1089554-3-nifan.cxl@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01hw/cxl/mailbox: change CCI cmd set structure to be a member, not a referenceGregory Price
This allows devices to have fully customized CCIs, along with complex devices where wrapper devices can override or add additional CCI commands without having to replicate full command structures or pollute a base device with every command that might ever be used. Signed-off-by: Gregory Price <gregory.price@memverge.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Fan Ni <fan.ni@samsung.com> Message-Id: <20240523174651.1089554-2-nifan.cxl@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01Revert "vhost-user: fix lost reconnect"Li Feng
This reverts commit f02a4b8e6431598612466f76aac64ab492849abf. Since the current patch cannot completely fix the lost reconnect problem, there is a scenario that is not considered: - When the virtio-blk driver is removed from the guest os, s->connected has no chance to be set to false, resulting in subsequent reconnection not being executed. The next patch will completely fix this issue with a better approach. Signed-off-by: Li Feng <fengli@smartx.com> Message-Id: <20240516025753.130171-2-fengli@smartx.com> Reviewed-by: Raphael Norwitz <raphael@enfabrica.net> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01virtio/virtio-pci: Handle extra notification dataJonah Palmer
Add support to virtio-pci devices for handling the extra data sent from the driver to the device when the VIRTIO_F_NOTIFICATION_DATA transport feature has been negotiated. The extra data that's passed to the virtio-pci device when this feature is enabled varies depending on the device's virtqueue layout. In a split virtqueue layout, this data includes: - upper 16 bits: shadow_avail_idx - lower 16 bits: virtqueue index In a packed virtqueue layout, this data includes: - upper 16 bits: 1-bit wrap counter & 15-bit shadow_avail_idx - lower 16 bits: virtqueue index Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Message-Id: <20240315165557.26942-2-jonah.palmer@oracle.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-01vhost: Perform memory section dirty scans once per iterationSi-Wei Liu
On setups with one or more virtio-net devices with vhost on, dirty tracking iteration increases cost the bigger the number amount of queues are set up e.g. on idle guests migration the following is observed with virtio-net with vhost=on: 48 queues -> 78.11% [.] vhost_dev_sync_region.isra.13 8 queues -> 40.50% [.] vhost_dev_sync_region.isra.13 1 queue -> 6.89% [.] vhost_dev_sync_region.isra.13 2 devices, 1 queue -> 18.60% [.] vhost_dev_sync_region.isra.14 With high memory rates the symptom is lack of convergence as soon as it has a vhost device with a sufficiently high number of queues, the sufficient number of vhost devices. On every migration iteration (every 100msecs) it will redundantly query the *shared log* the number of queues configured with vhost that exist in the guest. For the virtqueue data, this is necessary, but not for the memory sections which are the same. So essentially we end up scanning the dirty log too often. To fix that, select a vhost device responsible for scanning the log with regards to memory sections dirty tracking. It is selected when we enable the logger (during migration) and cleared when we disable the logger. If the vhost logger device goes away for some reason, the logger will be re-selected from the rest of vhost devices. After making mem-section logger a singleton instance, constant cost of 7%-9% (like the 1 queue report) will be seen, no matter how many queues or how many vhost devices are configured: 48 queues -> 8.71% [.] vhost_dev_sync_region.isra.13 2 devices, 8 queues -> 7.97% [.] vhost_dev_sync_region.isra.14 Co-developed-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com> Message-Id: <1710448055-11709-2-git-send-email-si-wei.liu@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
2024-07-01Merge tag 'pull-target-arm-20240701' of ↵Richard Henderson
https://git.linaro.org/people/pmaydell/qemu-arm into staging target-arm queue: * tests/avocado: update firmware for sbsa-ref and use all cores * hw/arm/smmu-common: Replace smmu_iommu_mr with smmu_find_sdev * arm: Fix VCMLA Dd, Dn, Dm[idx] * arm: Fix SQDMULH (by element) with Q=0 * arm: Fix FJCVTZS vs flush-to-zero * arm: More conversion of A64 AdvSIMD to decodetree * arm: Enable FEAT_Debugv8p8 for -cpu max * MAINTAINERS: Update family name for Patrick Leis * hw/arm/xilinx_zynq: Add boot-mode property * docs/system/arm: Add a doc for zynq board * hw/misc: In STM32L4x5 EXTI, correct configurable interrupts * tests/qtest: fix minor issues in STM32L4x5 tests # -----BEGIN PGP SIGNATURE----- # # iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmaC1BMZHHBldGVyLm1h # eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3nDOEACCoewjO2FJ4RFXMSmgr0Zf # jxWliu7osw7oeG4ZNq1+xMiXeW0vyS54eW41TMki1f98N/yK8v55BM8kBBvDvZaz # R5DUXpN+MtwD9A62md3B2c4mFXHqk1UOGbKi4btbtFj4lS8pV51mPmApzBUr2iTj # w6dCLciLOt87NWgtLECXsZ3evn+VlTRc+Hmfp1M/C/Rf2Qx3zis/CFHGQsZLGwzG # 2WhTpU1BKeOfsQa1VbSX6un14d72/JATFZN3rSgMbOEbvsCEeP+rnkzX57ejGyxV # 4DUx69gEAqS5bOfkQHLwy82WsunD/oIgp+GpYaYgINHzh6UkEsPoymrHAaPgV1Vh # g0TaBtbv2p89RFY1C2W2Mi4ICQ14a+oIV9FPvDsOE8Wq+wDAy/ZxZs7G6flxqods # s4JvcMqB3kUNBZaMsFVXTKdqT1PufICS+gx0VsKdKDwXcOHwMS10nTlEOPzqvoBA # phAsEbjnjWVhf03XTfCus+l5NT96lswCzPcUovb3CitSc2A1KUye3TyzHnxIqmOt # Owcl+Oiso++cgYzr/BCveTAYKYoRZzVcq5jCl4bBUH/8sLrRDbT0cpFpcMk72eE9 # VhR00kbkDfL3nKrulLsG8FeUlisX5+oGb3G5AdPtU9sqJPJMmBGaF+KniI0wi7VN # 5teHq08upLMF5JAjiKzZIA== # =faXD # -----END PGP SIGNATURE----- # gpg: Signature made Mon 01 Jul 2024 09:06:43 AM PDT # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [full] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [full] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [full] # gpg: aka "Peter Maydell <peter@archaic.org.uk>" [unknown] * tag 'pull-target-arm-20240701' of https://git.linaro.org/people/pmaydell/qemu-arm: (29 commits) tests/qtest: Ensure STM32L4x5 EXTI state is correct at the end of QTests hw/misc: In STM32L4x5 EXTI, correct configurable interrupts tests/qtest: Fix STM32L4x5 SYSCFG irq line 15 state assumption docs/system/arm: Add a doc for zynq board hw/arm/xilinx_zynq: Add boot-mode property hw/misc/zynq_slcr: Add boot-mode property MAINTAINERS: Update my family name target/arm: Enable FEAT_Debugv8p8 for -cpu max target/arm: Move initialization of debug ID registers target/arm: Fix indentation target/arm: Delete dead code from disas_simd_indexed target/arm: Convert FCMLA to decodetree target/arm: Convert FCADD to decodetree target/arm: Add data argument to do_fp3_vector target/arm: Convert BFMMLA, SMMLA, UMMLA, USMMLA to decodetree target/arm: Convert BFMLALB, BFMLALT to decodetree target/arm: Convert BFDOT to decodetree target/arm: Convert SUDOT, USDOT to decodetree target/arm: Convert SDOT, UDOT to decodetree target/arm: Convert SQRDMLAH, SQRDMLSH to decodetree ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-07-01hw/misc: In STM32L4x5 EXTI, correct configurable interruptsInès Varhol
The implementation of configurable interrupts (interrupts supporting edge selection) was incorrectly expecting alternating input levels : this commits adds a new status field `irq_levels` to actually detect edges. Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr> Message-id: 20240629110800.539969-2-ines.varhol@telecom-paris.fr Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-01hw/xen: detect when running inside stubdomainMarek Marczykowski-Górecki
Introduce global xen_is_stubdomain variable when qemu is running inside a stubdomain instead of dom0. This will be relevant for subsequent patches, as few things like accessing PCI config space need to be done differently. Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <e66aa97dca5120f22e015c19710b2ff04f525720.1711506237.git-series.marmarek@invisiblethingslab.com> Signed-off-by: Anthony PERARD <anthony@xenproject.org>
2024-07-01hw/arm/smmu-common: Replace smmu_iommu_mr with smmu_find_sdevNicolin Chen
The caller of smmu_iommu_mr wants to get sdev for smmuv3_flush_config(). Do it directly instead of bridging with an iommu mr pointer. Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Message-id: 20240619002218.926674-1-nicolinc@nvidia.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-01hw/misc: Implement mailbox properties for customer OTP and device specific ↵Rayhan Faizel
private keys Four mailbox properties are implemented as follows: 1. Customer OTP: GET_CUSTOMER_OTP and SET_CUSTOMER_OTP 2. Device-specific private key: GET_PRIVATE_KEY and SET_PRIVATE_KEY. The customer OTP is located in the rows 36-43. The device-specific private key is located in the rows 56-63. The customer OTP can be locked with the magic numbers 0xffffffff 0xaffe0000 when running the SET_CUSTOMER_OTP mailbox command. Bit 6 of row 32 indicates this lock, which is undocumented. The lock also applies to the device-specific private key. Signed-off-by: Rayhan Faizel <rayhan.faizel@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-01hw/arm: Connect OTP device to BCM2835Rayhan Faizel
Replace stubbed OTP memory region with the new OTP device. Signed-off-by: Rayhan Faizel <rayhan.faizel@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-01hw/nvram: Add BCM2835 OTP deviceRayhan Faizel
The OTP device registers are currently stubbed. For now, the device houses the OTP rows which will be accessed directly by other peripherals. Signed-off-by: Rayhan Faizel <rayhan.faizel@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-06-30monitor: Remove obsolete stubsPhilippe Mathieu-Daudé
hmp_info_roms() was removed in commit dd98234c05 ("qapi: introduce x-query-roms QMP command"), hmp_info_numa() in commit 1b8ae799d8 ("qapi: introduce x-query-numa QMP command"), hmp_info_ramblock() in commit ca411b7c8a ("qapi: introduce x-query-ramblock QMP command") and hmp_info_irq() in commit 91f2fa7045 ("qapi: introduce x-query-irq QMP command"). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-06-26hw/riscv/virt.c: add address-cells in create_fdt_one_aplic()Daniel Henrique Barboza
We need #address-cells properties in all interrupt controllers that are referred by an interrupt-map [1]. For the RISC-V machine, both PLIC and APLIC controllers must have this property. PLIC already sets it in create_fdt_socket_plic(). Set the property for APLIC in create_fdt_one_aplic(). [1] https://lore.kernel.org/linux-arm-kernel/CAL_JsqJE15D-xXxmELsmuD+JQHZzxGzdXvikChn6KFWqk6NzPw@mail.gmail.com/ Suggested-by: Anup Patel <apatel@ventanamicro.com> Fixes: e6faee65855b ("hw/riscv: virt: Add optional AIA APLIC support to virt machine") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240531202759.911601-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-06-24vfio/container: Move vfio_container_destroy() to an instance_finalize() handlerCédric Le Goater
vfio_container_destroy() clears the resources allocated VFIOContainerBase object. Now that VFIOContainerBase is a QOM object, add an instance_finalize() handler to do the cleanup. It will be called through object_unref(). Suggested-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-06-24vfio/container: Remove vfio_container_init()Cédric Le Goater
It's now empty. Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-06-24vfio/container: Remove VFIOContainerBase::opsCédric Le Goater
Instead, use VFIO_IOMMU_GET_CLASS() to get the class pointer. Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-06-24vfio/container: Change VFIOContainerBase to use QOMCédric Le Goater
VFIOContainerBase was made a QOM interface because we believed that a QOM object would expose all the IOMMU backends to the QEMU machine and human interface. This only applies to user creatable devices or objects. Change the VFIOContainerBase nature from interface to object and make the necessary adjustments in the VFIO_IOMMU hierarchy. Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-06-24vfio/container: Simplify vfio_container_init()Cédric Le Goater
Assign the base container VFIOAddressSpace 'space' pointer in vfio_address_space_insert(). The ultimate goal is to remove vfio_container_init() and instead rely on an .instance_init() handler to perfom the initialization of VFIOContainerBase. To be noted that vfio_connect_container() will assign the 'space' pointer later in the execution flow. This should not have any consequence. Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Tested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-06-24vfio/container: Introduce vfio_address_space_insert()Cédric Le Goater
It prepares ground for a future change initializing the 'space' pointer of VFIOContainerBase. The goal is to replace vfio_container_init() by an .instance_init() handler when VFIOContainerBase is QOMified. Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-06-24vfio: Remove unused declarations from vfio-common.hCédric Le Goater
These were forgotten in the recent cleanups. Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-06-24virtio-iommu: Implement set|unset]_iommu_device() callbacksEric Auger
Implement PCIIOMMUOPs [set|unset]_iommu_device() callbacks. In set(), the HostIOMMUDevice handle is stored in a hash table indexed by PCI BDF. The object will allow to retrieve information related to the physical IOMMU. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24intel_iommu: Implement [set|unset]_iommu_device() callbacksYi Liu
Implement [set|unset]_iommu_device() callbacks in Intel vIOMMU. In set call, we take a reference of HostIOMMUDevice and store it in hash table indexed by PCI BDF. Note this BDF index is device's real BDF not the aliased one which is different from the index of VTDAddressSpace. There can be multiple assigned devices under same virtual iommu group and share same VTDAddressSpace, but each has its own HostIOMMUDevice. Signed-off-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24hw/pci: Introduce pci_device_[set|unset]_iommu_device()Yi Liu
pci_device_[set|unset]_iommu_device() call pci_device_get_iommu_bus_devfn() to get iommu_bus->iommu_ops and call [set|unset]_iommu_device callback to set/unset HostIOMMUDevice for a given PCI device. Signed-off-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24vfio: Create host IOMMU device instanceZhenzhong Duan
Create host IOMMU device instance in vfio_attach_device() and call .realize() to initialize it further. Introuduce attribute VFIOIOMMUClass::hiod_typename and initialize it based on VFIO backend type. It will facilitate HostIOMMUDevice creation in vfio_attach_device(). Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24vfio/container: Implement HostIOMMUDeviceClass::realize() handlerZhenzhong Duan
The realize function populates the capabilities. For now only the aw_bits caps is computed for legacy backend. Introduce a helper function vfio_device_get_aw_bits() which calls range_get_last_bit() to get host aw_bits and package it in HostIOMMUDeviceCaps for query with .get_cap(). This helper will also be used by iommufd backend. Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24backends/iommufd: Introduce TYPE_HOST_IOMMU_DEVICE_IOMMUFD[_VFIO] devicesZhenzhong Duan
TYPE_HOST_IOMMU_DEVICE_IOMMUFD represents a host IOMMU device under iommufd backend. It is abstract, because it is going to be derived into VFIO or VDPA type'd device. It will have its own .get_cap() implementation. TYPE_HOST_IOMMU_DEVICE_IOMMUFD_VFIO is a sub-class of TYPE_HOST_IOMMU_DEVICE_IOMMUFD, represents a VFIO type'd host IOMMU device under iommufd backend. It will be created during VFIO device attaching and passed to vIOMMU. It will have its own .realize() implementation. Opportunistically, add missed header to include/sysemu/iommufd.h. Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24vfio/container: Introduce TYPE_HOST_IOMMU_DEVICE_LEGACY_VFIO deviceZhenzhong Duan
TYPE_HOST_IOMMU_DEVICE_LEGACY_VFIO represents a host IOMMU device under VFIO legacy container backend. It will have its own realize implementation. Suggested-by: Eric Auger <eric.auger@redhat.com> Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2024-06-24s390x/css: Make S390CCWDeviceClass::realize return boolCédric Le Goater
Since the realize() handler of S390CCWDeviceClass takes an 'Error **' argument, best practices suggest to return a bool. See the api/error.h Rules section. While at it, modify the call in vfio_ccw_realize(). Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20240522170107.289532-5-clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-06-21hw/arm/virt: allow creation of a second NonSecure UARTPeter Maydell
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
2024-06-21hw/arm/virt: Rename VIRT_UART and VIRT_SECURE_UART to VIRT_UART[01]Peter Maydell
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
2024-06-19hw/s390x: Introduce s390_skeys_get|set() helpersPhilippe Mathieu-Daudé
s390_skeys_set() dispatch to S390SKeysClass::set_skeys(), and s390_skeys_get() to S390SKeysClass::get_skeys(). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20240613104415.9643-2-philmd@linaro.org>
2024-06-19hw/intc/loongson_ipi: Provide per core MMIO address spacesJiaxun Yang
The real IPI hardware have dedicated MMIO registers mapped into memory address space for every core. This is not used by LoongArch guest software but it is essential for CPU without IOCSR such as Loongson-3A1000. Implement it with existing infrastructure. Acked-by: Song Gao <gaosong@loongson.cn> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Message-ID: <20240605-loongson3-ipi-v3-2-ddd2c0e03fa3@flygoat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-06-19hw/intc: Avoid using Monitor in INTERRUPT_STATS_PROVIDER::print_info()Philippe Mathieu-Daudé
Replace Monitor API by HumanReadableText one (see commit f2de406f29 "docs/devel: document expectations for QAPI data modelling for QMP" for rationale). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20240610063518.50680-2-philmd@linaro.org>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-16 17:00:00 +0000