aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
2024-03-26hw/misc/stm32l4x5_rcc: Propagate period when enabling a clockArnaud Minier
The "clock_set_mul_div" function doesn't propagate the clock period to the children if it is changed (e.g. by enabling/disabling a clock multiplexer). This was overlooked during the implementation due to late changes. This commit propagates the change if the multiplier or divider changes. Fixes: ec7d83acbd ("hw/misc/stm32l4x5_rcc: Add an internal clock multiplexer object") Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr> Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr> Message-ID: <20240317103918.44375-2-arnaud.minier@telecom-paris.fr> [PMD: Check clock_set_mul_div() return value] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20240325152827.73817-4-philmd@linaro.org>
2024-03-26hw/misc/stm32l4x5_rcc: Inline clock_update() in clock_mux_update()Philippe Mathieu-Daudé
Trivial inlining in preliminary patch to make the next one easier to review. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20240325152827.73817-3-philmd@linaro.org>
2024-03-26hw/clock: Let clock_set_mul_div() return a boolean valuePhilippe Mathieu-Daudé
Let clock_set_mul_div() return a boolean value whether the clock has been updated or not, similarly to clock_set(). Return early when clock_set_mul_div() is called with same mul/div values the clock has. Acked-by: Luc Michel <luc@lmichel.fr> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20240325152827.73817-2-philmd@linaro.org>
2024-03-26hw/scsi/scsi-generic: Fix io_timeout property not applyingLorenz Brun
The io_timeout property, introduced in c9b6609 (part of 6.0) is silently overwritten by the hardcoded default value of 30 seconds (DEFAULT_IO_TIMEOUT) in scsi_generic_realize because that function is being called after the properties have already been applied. The property definition already has a default value which is applied correctly when no value is explicitly set, so we can just remove the code which overrides the io_timeout completely. This has been tested by stracing SG_IO operations with the io_timeout property set and unset and now sets the timeout field in the ioctl request to the proper value. Fixes: c9b6609b69facad ("scsi: make io_timeout configurable") Signed-off-by: Lorenz Brun <lorenz@brun.one> Message-ID: <20240315145831.2531695-1-lorenz@brun.one> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-03-26vdpa-dev: Fix initialisation order to restore VDUSE compatibilityKevin Wolf
VDUSE requires that virtqueues are first enabled before the DRIVER_OK status flag is set; with the current API of the kernel module, it is impossible to enable the opposite order in our block export code because userspace is not notified when a virtqueue is enabled. This requirement also mathces the normal initialisation order as done by the generic vhost code in QEMU. However, commit 6c482547 accidentally changed the order for vdpa-dev and broke access to VDUSE devices with this. This changes vdpa-dev to use the normal order again and use the standard vhost callback .vhost_set_vring_enable for this. VDUSE devices can be used with vdpa-dev again after this fix. vhost_net intentionally avoided enabling the vrings for vdpa and does this manually later while it does enable them for other vhost backends. Reflect this in the vhost_net code and return early for vdpa, so that the behaviour doesn't change for this device. Cc: qemu-stable@nongnu.org Fixes: 6c4825476a43 ('vdpa: move vhost_vdpa_set_vring_ready to the caller') Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20240315155949.86066-1-kwolf@redhat.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2024-03-25Merge tag 'pull-request-2024-03-25' of https://gitlab.com/thuth/qemu into ↵Peter Maydell
staging * Fix timeouts in Travis-CI jobs * Mark devices with user_creatable = false that can crash QEMU otherwise * Fix s390x TEST-AND-SET TCG instruction emulation * Move pc955* devices to hw/gpio/ # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmYBhdgRHHRodXRoQHJl # ZGhhdC5jb20ACgkQLtnXdP5wLbVcfA/9FulEN4HrjD3ObyboA+WfibXURwChui98 # 8LvL/fAGe3BZXQtspuNmPyrKRtIOrIwHJyFuxf2N5+8BuvGhEHQIuvIhQIj/rvfy # X14KlldmQ3w3HlI3Ud4YiebLyK3AAFC2ApIywzFsnN+HoaHJR2EyDIb+T7OsGJZf # ZLE/Z7qANxoNeZ+a3+rQR3SVpijyS3fXxDSaILrq2uW4kCCs/55O8Rt3Qb+PFSVd # fF+OlpG6o+z73ACZc1u9Io4IO1ZZc/NdkmDTNz4HknkvJLTLF6kOECAxLl0ytgAG # YRzBGKes29Zpa9wn/9rc75/OYNS0Ks+B19sQnijWUNX0zq5FkReXNXiyVcbT7d4p # 6jFzlFnjj4ifB8uQkZTGcx/lL4s4VkPzF+f7fgHq9CKNrNsx8uca0TyQ8s4y+NGb # C98kJdHd+QhCcuNnAbifCwuFaxQ8C4BdgzxVbU/sGDKNkINNkiTp+uue4TxnRKvV # MfhqdnWRvqgZ0Rl4TxqcNfODK72Z1YNv3933OKE/mRJYS1Q529TIq4vfp8WIMsWQ # 7+ipo4WKXhkiSOJZD6AkCoFum1W8yaDzUDJTw2Xt2bPBL3+FXcQyKkKVUMfzIJ8M # KLe0Bb9W/pYU1ToTciTP0dkQF/02tG0Vik273445wPgH0x8OyHJkPF/ny1a7lKFO # 5jreYdMxWdc= # =lfZM # -----END PGP SIGNATURE----- # gpg: Signature made Mon 25 Mar 2024 14:10:32 GMT # gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5 # gpg: issuer "thuth@redhat.com" # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * tag 'pull-request-2024-03-25' of https://gitlab.com/thuth/qemu: tests/tcg/s390x: Test TEST AND SET target/s390x: Use mutable temporary value for op_ts libqos/virtio.c: Correct 'flags' reading in qvirtqueue_kick misc/pca955*: Move models under hw/gpio aspeed: Make the ast1030-a1 SoC not user creatable aspeed: Make the ast2600-a3 SoC not user creatable hw/microblaze: Do not allow xlnx-zynqmp-pmu-soc to be created by the user .travis.yml: Remove the unused xfslib-dev package .travis.yml: Shorten the runtime of the problematic jobs Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-03-25misc/pca955*: Move models under hw/gpioCédric Le Goater
The PCA9552 and PCA9554 devices are both I2C GPIO controllers and the PCA9552 also can drive LEDs. Do all the necessary adjustments to move the models under hw/gpio. Cc: Glenn Miles <milesg@linux.vnet.ibm.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Message-ID: <20240325134833.1484265-1-clg@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-03-25hw/nvram/mac_nvram: Report failure to write dataPeter Maydell
There's no way for the macio_nvram device to report failure to write data, but we can at least report it to the user with error_report() as we do in other devices like xlnx-efuse. Spotted by Coverity. Resolves: Coverity CID 1507628 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240312183810.557768-6-peter.maydell@linaro.org
2024-03-25hw/misc/pca9554: Correct error check bounds in get/set pin functionsPeter Maydell
In pca9554_get_pin() and pca9554_set_pin(), we try to detect an incorrect pin value, but we get the condition wrong, using ">" when ">=" was intended. This has no actual effect, because in pca9554_initfn() we use the correct test when creating the properties and so we'll never be called with an out of range value. However, Coverity complains about the mismatch between the check and the later use of the pin value in a shift operation. Use the correct condition. Resolves: Coverity CID 1534917 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-id: 20240312183810.557768-5-peter.maydell@linaro.org
2024-03-25aspeed: Make the ast1030-a1 SoC not user creatableCédric Le Goater
Aspeed SoCs are complex devices that can not be specified on the command line. Fix that to avoid QEMU aborts. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2227 Fixes: 356b230ed138 ("aspeed/soc : Add AST1030 support") Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240319150903.413662-2-clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-03-25aspeed: Make the ast2600-a3 SoC not user creatableCédric Le Goater
Aspeed SoCs are complex devices that can not be specified on the command line. Fix that to avoid QEMU aborts. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2227 Fixes: f25c0ae1079d ("aspeed/soc: Add AST2600 support") Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240319150903.413662-1-clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-03-25hw/microblaze: Do not allow xlnx-zynqmp-pmu-soc to be created by the userThomas Huth
Using xlnx-zynqmp-pmu-soc on the command line causes QEMU to crash: ./qemu-system-microblazeel -M petalogix-ml605 -device xlnx-zynqmp-pmu-soc ** ERROR:tcg/tcg.c:813:tcg_register_thread: assertion failed: (n < tcg_max_ctxs) Bail out! Aborted (core dumped) Mark the device with "user_creatable = false" to avoid that this can happen. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2229 Message-ID: <20240322183153.1023359-1-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-03-22target/riscv/kvm: fix timebase-frequency when using KVM accelerationYong-Xuan Wang
The timebase-frequency of guest OS should be the same with host machine. The timebase-frequency value in DTS should be got from hypervisor when using KVM acceleration. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Message-ID: <20240314061510.9800-1-yongxuan.wang@sifive.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-22hw/intc: Update APLIC IDC after claiming iforce registerFrank Chang
Currently, QEMU only sets the iforce register to 0 and returns early when claiming the iforce register. However, this may leave mip.meip remains at 1 if a spurious external interrupt triggered by iforce register is the only pending interrupt to be claimed, and the interrupt cannot be lowered as expected. This commit fixes this issue by calling riscv_aplic_idc_update() to update the IDC status after the iforce register is claimed. Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240321104951.12104-1-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-20hw/intc/loongarch_extioi: Fix interrupt routing updateBibo Mao
Interrupt number in loop sentence should be base irq plus loop index, it is missing on checking whether the irq is pending. Fixes: 428a6ef4396 ("Add vmstate post_load support") Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn> Message-Id: <20240313093932.2653518-1-maobibo@loongson.cn>
2024-03-19Merge tag 'pull-for-9.0-20240319' of https://github.com/legoater/qemu into ↵Peter Maydell
staging aspeed, pnv, vfio queue: * user device fixes for Aspeed and PowerNV machines * coverity fix for iommufd # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEoPZlSPBIlev+awtgUaNDx8/77KEFAmX5mm0ACgkQUaNDx8/7 # 7KE/MQ/9GeX4yNBxY2iTATdmPXwjMw8AtKyfIQb605nIO0ch1Z98ywl5VMwCNohn # ppY9L5bFpEASgRlFVm73X4DGxKyRGpRPqylsvINh0hKciRpmRkELHY3llhnXsd7P # Q197pDtFr54FeX8j4+hSAu4paT97fPENlKn0J6lto2I1cXGcD1LYNDFhysoXdGme # brJgo7KjQJZPZ560ZewskL5FWf3G9EkRjpqd8y0G5OtNmAPgAaahOMHhDCXan182 # J89I9CHI5xN45MRfAs8JamSaj/GyNsr4h04WhPa0+VZQ5vsaeW2Ekt4ypj+oAV+p # wykhYzQk4ALZcmmph2flSAtLa7uheI+imyqubMthQCDj3G8onSQBMd5/4WRK6O49 # 0oE1DpPDEfhlJEQYxaYhOeqeA9iaP+w6V+yE+L5oGlMO66cR7GZsPu0x7kXailbH # IoHw9mO+vMkpuyeP7M3hA8WRFCdFpf1Nn1Ao5Jz3KoiTyJWlIvX5VSaj12sjddQ2 # fU9SKu2Q5QqS5uQGakkY64EyUy7RkGIX6zY2NIscVe2lfAfKf3mZwu7OIuLjEy5O # lRn35vWV8fOdRooKoDPTNcdBCaNPi+RApin8chOv5P+F+ie7+Twf9sb1AgH/pIcv # HptvTXbvSFNbbdb+OE8a5qsqTvnrN8d31IXzrWRYsJB07x2IyoA= # =zR3v # -----END PGP SIGNATURE----- # gpg: Signature made Tue 19 Mar 2024 14:00:13 GMT # gpg: using RSA key A0F66548F04895EBFE6B0B6051A343C7CFFBECA1 # gpg: Good signature from "Cédric Le Goater <clg@kaod.org>" [undefined] # 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: A0F6 6548 F048 95EB FE6B 0B60 51A3 43C7 CFFB ECA1 * tag 'pull-for-9.0-20240319' of https://github.com/legoater/qemu: aspeed/smc: Only wire flash devices at reset ppc/pnv: I2C controller is not user creatable vfio/iommufd: Fix memory leak Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-03-19aspeed/smc: Only wire flash devices at resetCédric Le Goater
The Aspeed machines have many Static Memory Controllers (SMC), up to 8, which can only drive flash memory devices. Commit 27a2c66c92ec ("aspeed/smc: Wire CS lines at reset") tried to ease the definitions of these devices by allowing flash devices from the command line to be attached to a SSI bus. For that, the wiring of the CS lines of the Aspeed SMC controller was moved at reset. Two assumptions are made though, first that the device has a SSI_GPIO_CS GPIO line, which is not always the case, and second that it is a flash device. Correct this problem by ensuring that the devices attached to the bus are of the correct flash type. This fixes a QEMU abort when devices without a CS line, such as the max111x, are passed on the command line. While at it, export TYPE_M25P80 used in the Xilinx Versal Virtual machine. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2228 Fixes: 27a2c66c92ec ("aspeed/smc: Wire CS lines at reset") Reported-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> [ clg: minor fixes in the commit log ] Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-03-19ppc/pnv: I2C controller is not user creatableCédric Le Goater
The I2C controller is a subunit of the processor. Make it so and avoid QEMU crashes. $ build/qemu-system-ppc64 -S -machine powernv9 -device pnv-i2c qemu-system-ppc64: ../hw/ppc/pnv_i2c.c:521: pnv_i2c_realize: Assertion `i2c->chip' failed. Aborted (core dumped) Fixes: 263b81ee15af ("ppc/pnv: Add an I2C controller model") Cc: Glenn Miles <milesg@linux.vnet.ibm.com> Reported-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Glenn Miles <milesg@linux.vnet.ibm.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-03-19vfio/iommufd: Fix memory leakCédric Le Goater
Coverity reported a memory leak on variable 'contents' in routine iommufd_cdev_getfd(). Use g_autofree variables to simplify the exit path and get rid of g_free() calls. Cc: Eric Auger <eric.auger@redhat.com> Cc: Yi Liu <yi.l.liu@intel.com> Fixes: CID 1540007 Fixes: 5ee3dc7af785 ("vfio/iommufd: Implement the iommufd backend") Suggested-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-03-18smbios: add extra comments to smbios_get_table_legacy()Igor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20240314152302.2324164-22-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18pc/q35: set SMBIOS entry point type to 'auto' by defaultIgor Mammedov
Use smbios-entry-point-type='auto' for newer machine types as a workaround for Windows not detecting SMBIOS tables. Which makes QEMU pick SMBIOS tables based on configuration (with 2.x preferred and fallback to 3.x if the former isn't compatible with configuration) Default compat setting of smbios-entry-point-type after series for pc/q35 machines: * 9.0-newer: 'auto' * 8.1-8.2: '64' * 8.0-older: '32' Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2008 Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-20-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: error out when building type 4 table is not possibleIgor Mammedov
If SMBIOS v2 version is requested but number of cores/threads are more than it's possible to describe with v2, error out instead of silently ignoring the fact and filling core/thread count with bogus values. This will help caller to decide if it should fallback to SMBIOSv3 when smbios-entry-point-type='auto' Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-18-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: in case of entry point is 'auto' try to build v2 tables 1stIgor Mammedov
QEMU for some time now uses SMBIOS 3.0 for PC/Q35 machines by default, however Windows has a bug in locating SMBIOS 3.0 entrypoint and fails to find tables when booted on SeaBIOS (on UEFI SMBIOS 3.0 tables work fine since firmware hands over tables in another way) Missing SMBIOS tables may lead to some issues for guest though (worst are: possible reactiveation, inability to get virtio drivers from 'Windows Update') It's unclear at this point if MS will fix the issue on their side. So instead of it (or rather in addition) this patch will try to workaround the issue. aka, use smbios-entry-point-type=auto to make QEMU try generating conservative SMBIOS 2.0 tables and if that fails (due to limits/requested configuration) fallback to SMBIOS 3.0 tables. With this in place majority of users will use SMBIOS 2.0 tables which work fine with (Windows + legacy BIOS). The configurations that is not to possible to describe with SMBIOS 2.0 will switch automatically to SMBIOS 3.0 (which will trigger Windows bug but there is nothing QEMU can do here, so go and aks Microsoft to real fix). Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-17-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: clear smbios_type4_count before building tablesIgor Mammedov
it will help to keep type 4 tables accounting correct in case SMBIOS tables are built multiple times. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-15-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: get rid of global smbios_ep_typeIgor Mammedov
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-14-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: handle errors consistentlyIgor Mammedov
Current code uses mix of error_report()+exit(1) and error_setg() to handle errors. Use newer error_setg() everywhere, beside consistency it will allow to detect error condition without killing QEMU and attempt switch-over to SMBIOS3.x tables/entrypoint in follow up patch. while at it, clear smbios_tables pointer after freeing. that will avoid double free if smbios_get_tables() is called multiple times. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20240314152302.2324164-13-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: build legacy mode code only for 'pc' machineIgor Mammedov
basically moving code around without functional change. And exposing some symbols so that they could be shared between smbbios.c and new smbios_legacy.c plus some meson magic to build smbios_legacy.c only for 'pc' machine and otherwise replace it with stub if not selected. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20240314152302.2324164-12-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: rename/expose structures/bitmaps used by both legacy and modern codeIgor Mammedov
As a preparation to move legacy handling into a separate file, add prefix 'smbios_' to type0/type1/have_binfile_bitmap/have_fields_bitmap and expose them in smbios.h so that they can be reused in legacy and modern code. Doing it as a separate patch to avoid rename cluttering follow-up patch which will move legacy code into a separate file. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20240314152302.2324164-11-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: add smbios_add_usr_blob_size() helperIgor Mammedov
it will be used by follow up patch when legacy handling is moved out into a separate file. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20240314152302.2324164-10-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: don't check type4 structures in legacy modeIgor Mammedov
legacy mode doesn't support structures of type 2 and more, and CLI has a check for '-smbios type' option, however it's still possible to sneak in type4 as a blob with '-smbios file' option. However doing the later makes SMBIOS tables broken since SeaBIOS doesn't expect that. Rather than trying to add support for type4 to legacy code (both QEMU and SeaBIOS), simplify smbios_get_table_legacy() by dropping not relevant check in legacy code and error out on type4 blob. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-9-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: avoid mangling user provided tablesIgor Mammedov
currently smbios_entry_add() preserves internally '-smbios type=' options but tables provided with '-smbios file=' are stored directly into blob that eventually will be exposed to VM. And then later QEMU adds default/'-smbios type' entries on top into the same blob. It makes impossible to generate tables more than once, hence 'immutable' guard was used. Make it possible to regenerate final blob by storing user provided blobs into a dedicated area (usr_blobs) and then copy it when composing final blob. Which also makes handling of -smbios options consistent. As side effect of this and previous commits there is no need to generate legacy smbios_entries at the time options are parsed. Instead compose smbios_entries on demand from usr_blobs like it is done for non-legacy SMBIOS tables. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20240314152302.2324164-8-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: get rid of smbios_legacy globalIgor Mammedov
clean up smbios_set_defaults() which is reused by legacy and non legacy machines from being aware of 'legacy' notion and need to turn it off. And push legacy handling up to PC machine code where it's relevant. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Acked-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-7-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: get rid of smbios_smp_sockets globalIgor Mammedov
it makes smbios_validate_table() independent from smbios_smp_sockets global, which in turn lets smbios_get_tables() avoid using not related legacy code. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-6-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18smbios: cleanup smbios_get_tables() from legacy handlingIgor Mammedov
smbios_get_tables() bails out right away if leagacy mode is enabled and won't generate any SMBIOS tables. At the same time x86 specific fw_cfg_build_smbios() will genarate legacy tables and then proceed to preparing temporary mem_array for useless call to smbios_get_tables() and then discard it. Drop legacy related check in smbios_get_tables() and return from fw_cfg_build_smbios() early if legacy tables where built without proceeding to non legacy part of the function. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Message-Id: <20240314152302.2324164-5-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-18SMBIOS: fix long linesMichael S. Tsirkin
Break up long lines to fit under 80/90 char limit. Fixes: 04f143d828 ("Implement SMBIOS type 9 v2.6") Fixes: 735eee07d1 ("Implement base of SMBIOS type 9 descriptor.") Cc: "Felix Wu" <flwu@google.com> Cc: Nabih Estefan <nabihestefan@google.com> Reviewed-by: Ani Sinha <anisinha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-13Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Peter Maydell
into staging virtio,pc,pci: features, cleanups, fixes more memslots support in libvhost-user support PCIe Gen5/Gen6 link speeds in pcie more traces in vdpa network simulation devices support in vdpa SMBIOS type 9 descriptor implementation Bump max_cpus to 4096 vcpus in q35 aw-bits and granule options in VIRTIO-IOMMU Support report NUMA nodes for device memory using GI in acpi Beginning of shutdown event support in pvpanic fixes, cleanups all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # -----BEGIN PGP SIGNATURE----- # # iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmXw0TMPHG1zdEByZWRo # YXQuY29tAAoJECgfDbjSjVRp8x4H+gLMoGwaGAX7gDGPgn2Ix4j/3kO77ZJ9X9k/ # 1KqZu/9eMS1j2Ei+vZqf05w7qRjxxhwDq3ilEXF/+UFqgAehLqpRRB8j5inqvzYt # +jv0DbL11PBp/oFjWcytm5CbiVsvq8KlqCF29VNzc162XdtcduUOWagL96y8lJfZ # uPrOoyeR7SMH9lp3LLLHWgu+9W4nOS03RroZ6Umj40y5B7yR0Rrppz8lMw5AoQtr # 0gMRnFhYXeiW6CXdz+Tzcr7XfvkkYDi/j7ibiNSURLBfOpZa6Y8+kJGKxz5H1K1G # 6ZY4PBcOpQzl+NMrktPHogczgJgOK10t+1i/R3bGZYw2Qn/93Eg= # =C0UU # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 22:03:31 GMT # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (68 commits) docs/specs/pvpanic: document shutdown event hw/cxl: Fix missing reserved data in CXL Device DVSEC hmat acpi: Fix out of bounds access due to missing use of indirection hmat acpi: Do not add Memory Proximity Domain Attributes Structure targetting non existent memory. qemu-options.hx: Document the virtio-iommu-pci aw-bits option hw/arm/virt: Set virtio-iommu aw-bits default value to 48 hw/i386/q35: Set virtio-iommu aw-bits default value to 39 virtio-iommu: Add an option to define the input range width virtio-iommu: Trace domain range limits as unsigned int qemu-options.hx: Document the virtio-iommu-pci granule option virtio-iommu: Change the default granule to the host page size virtio-iommu: Add a granule property hw/i386/acpi-build: Add support for SRAT Generic Initiator structures hw/acpi: Implement the SRAT GI affinity structure qom: new object to associate device to NUMA node hw/i386/pc: Inline pc_cmos_init() into pc_cmos_init_late() and remove it hw/i386/pc: Set "normal" boot device order in pc_basic_device_init() hw/i386/pc: Avoid one use of the current_machine global hw/i386/pc: Remove "rtc_state" link again Revert "hw/i386/pc: Confine system flash handling to pc_sysfw" ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # hw/core/machine.c
2024-03-13Merge tag 'pull-ppc-for-9.0-2-20240313' of https://gitlab.com/npiggin/qemu ↵Peter Maydell
into staging * PAPR nested hypervisor host implementation for spapr TCG * excp_helper.c code cleanups and improvements * Move more ops to decodetree * Deprecate pseries-2.12 machines and P9 and P10 DD1.0 CPUs * Document running Linux on AmigaNG * Update dt feature advertising POWER CPUs. * Add P10 PMU SPRs * Improve pnv topology calculation for SMT8 CPUs. * Various bug fixes. # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCgAdFiEETkN92lZhb0MpsKeVZ7MCdqhiHK4FAmXwiT8ACgkQZ7MCdqhi # HK7C/w//XxEO2bQTFPLFDTrP/voq7pcX8XeQNVyXCkXYjvsbu05oQow50k+Y5UAE # US4MFjt8jFz0vuIKuKyoA3kG41zDSOzoX4TQXMM+tyTWbuFF3KAyfizb1xE6SYAN # xJEGvmiXv/EgoSBD7BTKQp1tMPdIGZLwSdYiA0lmOo7YaMCgYAXaujW5hnNjQecT # 873sN+10pHtQY++mINtD9Nfb6AcDGMWw0b+bykqIXhNRkI8IGOS4WF4vAuMBrwfe # UM00wDnNRb86Dk14bv2XVNDr6/i0VRtUMwM4yiptrQ1TQx18LZaPSQFYjQfPaan7 # LwN4QkMFnBX54yJ7Npvjvu8BCBF47kwOVu4CIAFJ4sIm0WfTmozDpPttwcZ5w7Ve # iXDOB9ECAB4pQ2rCgbSNG8MYUZgoHHOuThqolOP0Vh9NHRRJxpdw6CyAbmCGftc0 # lvRDPFiKp8xmCNJ/j3XzoUdHoG7NMwpUmHv9ruGU18SdQ8hyJN9AcQGWYrB4v0RV # /hs2RAbwntG7ahkcwd8uy5aFw88Wph/uGXPXc49EWj7i49vHeIV2y5+gtthMywje # qqjFXkistXuF+JHVnyoYmqqCyXaHX5CEwtawMv4EQeaJs76bLhMeMTKKl9rRp8qB # DtbIZphO8iMsocrBnje48sA5HR0PM+H4HTjw10i8R0fLlWitaIY= # =XnY5 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 16:56:31 GMT # gpg: using RSA key 4E437DDA56616F4329B0A79567B30276A8621CAE # gpg: Good signature from "Nicholas Piggin <npiggin@gmail.com>" [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: 4E43 7DDA 5661 6F43 29B0 A795 67B3 0276 A862 1CAE * tag 'pull-ppc-for-9.0-2-20240313' of https://gitlab.com/npiggin/qemu: (38 commits) spapr: nested: Introduce cap-nested-papr for Nested PAPR API spapr: nested: Introduce H_GUEST_RUN_VCPU hcall. spapr: nested: Use correct source for parttbl info for nested PAPR API. spapr: nested: Introduce H_GUEST_[GET|SET]_STATE hcalls. spapr: nested: Initialize the GSB elements lookup table. spapr: nested: Extend nested_ppc_state for nested PAPR API spapr: nested: Introduce H_GUEST_CREATE_VCPU hcall. spapr: nested: Introduce H_GUEST_[CREATE|DELETE] hcalls. spapr: nested: Introduce H_GUEST_[GET|SET]_CAPABILITIES hcalls. spapr: nested: Document Nested PAPR API spapr: nested: keep nested-hv related code restricted to its API. spapr: nested: Introduce SpaprMachineStateNested to store related info. spapr: nested: move nested part of spapr_get_pate into spapr_nested.c spapr: nested: register nested-hv api hcalls only for cap-nested-hv target/ppc: Remove interrupt handler wrapper functions target/ppc: Clean up ifdefs in excp_helper.c, part 3 target/ppc: Clean up ifdefs in excp_helper.c, part 2 target/ppc: Clean up ifdefs in excp_helper.c, part 1 target/ppc: Add gen_exception_err_nip() function target/ppc: Readability improvements in exception handlers ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-03-12hmat acpi: Fix out of bounds access due to missing use of indirectionJonathan Cameron
With a numa set up such as -numa nodeid=0,cpus=0 \ -numa nodeid=1,memdev=mem \ -numa nodeid=2,cpus=1 and appropriate hmat_lb entries the initiator list is correctly computed and writen to HMAT as 0,2 but then the LB data is accessed using the node id (here 2), landing outside the entry_list array. Stash the reverse lookup when writing the initiator list and use it to get the correct array index index. Fixes: 4586a2cb83 ("hmat acpi: Build System Locality Latency and Bandwidth Information Structure(s)") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20240307160326.31570-3-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12hmat acpi: Do not add Memory Proximity Domain Attributes Structure ↵Jonathan Cameron
targetting non existent memory. If qemu is started with a proximity node containing CPUs alone, it will provide one of these structures to say memory in this node is directly connected to itself. This description is arguably pointless even if there is memory in the node. If there is no memory present, and hence no SRAT entry it breaks Linux HMAT passing and the table is rejected. https://elixir.bootlin.com/linux/v6.7/source/drivers/acpi/numa/hmat.c#L444 Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20240307160326.31570-2-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12hw/arm/virt: Set virtio-iommu aw-bits default value to 48Eric Auger
On ARM we set 48b as a default (matching SMMUv3 SMMU_IDR5.VAX == 0). hw_compat_8_2 is used to handle the compatibility for machine types before 9.0 (default was 64 bits). Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Zhenzhong Duan <Zhenzhong.duan@intel.com> Message-Id: <20240307134445.92296-9-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12hw/i386/q35: Set virtio-iommu aw-bits default value to 39Eric Auger
Currently the default input range can extend to 64 bits. On x86, when the virtio-iommu protects vfio devices, the physical iommu may support only 39 bits. Let's set the default to 39, as done for the intel-iommu. We use hw_compat_8_2 to handle the compatibility for machines before 9.0 which used to have a virtio-iommu default input range of 64 bits. Of course if aw-bits is set from the command line, the default is overriden. Signed-off-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20240307134445.92296-8-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
2024-03-12virtio-iommu: Add an option to define the input range widthEric Auger
aw-bits is a new option that allows to set the bit width of the input address range. This value will be used as a default for the device config input_range.end. By default it is set to 64 bits which is the current value. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-Id: <20240307134445.92296-7-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12virtio-iommu: Trace domain range limits as unsigned intEric Auger
Use %u format to trace domain_range limits. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-Id: <20240307134445.92296-6-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12virtio-iommu: Change the default granule to the host page sizeEric Auger
We used to set the default granule to 4KB but with VFIO assignment it makes more sense to use the actual host page size. Indeed when hotplugging a VFIO device protected by a virtio-iommu on a 64kB/64kB host/guest config, we current get a qemu crash: "vfio: DMA mapping failed, unable to continue" This is due to the hot-attached VFIO device calling memory_region_iommu_set_page_size_mask() with 64kB granule whereas the virtio-iommu granule was already frozen to 4KB on machine init done. Set the granule property to "host" and introduce a new compat. The page size mask used before 9.0 was qemu_target_page_mask(). Since the virtio-iommu currently only supports x86_64 and aarch64, this matched a 4KB granule. Note that the new default will prevent 4kB guest on 64kB host because the granule will be set to 64kB which would be larger than the guest page size. In that situation, the virtio-iommu driver fails on viommu_domain_finalise() with "granule 0x10000 larger than system page size 0x1000". In that case the workaround is to request 4K granule. The current limitation of global granule in the virtio-iommu should be removed and turned into per domain granule. But until we get this upgraded, this new default is probably better because I don't think anyone is currently interested in running a 4KB page size guest with virtio-iommu on a 64KB host. However supporting 64kB guest on 64kB host with virtio-iommu and VFIO looks a more important feature. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Message-Id: <20240307134445.92296-4-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12virtio-iommu: Add a granule propertyEric Auger
This allows to choose which granule will be used by default by the virtio-iommu. Current page size mask default is qemu_target_page_mask so this translates into a 4k granule on ARM and x86_64 where virtio-iommu is supported. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Message-Id: <20240307134445.92296-3-eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12hw/i386/acpi-build: Add support for SRAT Generic Initiator structuresAnkit Agrawal
The acpi-generic-initiator object is added to allow a host device to be linked with a NUMA node. Qemu use it to build the SRAT Generic Initiator Affinity structure [1]. Add support for i386. [1] ACPI Spec 6.3, Section 5.2.16.6 Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Message-Id: <20240308145525.10886-4-ankita@nvidia.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-03-12hw/acpi: Implement the SRAT GI affinity structureAnkit Agrawal
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>
2024-03-12qom: new object to associate device to NUMA nodeAnkit Agrawal
NVIDIA GPU's support MIG (Mult-Instance GPUs) feature [1], which allows partitioning of the GPU device resources (including device memory) into several (upto 8) isolated instances. Each of the partitioned memory needs a dedicated NUMA node to operate. The partitions are not fixed and they can be created/deleted at runtime. Unfortunately Linux OS does not provide a means to dynamically create/destroy NUMA nodes and such feature implementation is not expected to be trivial. The nodes that OS discovers at the boot time while parsing SRAT remains fixed. So we utilize the Generic Initiator (GI) Affinity structures that allows association between nodes and devices. Multiple GI structures per BDF is possible, allowing creation of multiple nodes by exposing unique PXM in each of these structures. Implement the mechanism to build the GI affinity structures as Qemu currently does not. Introduce a new acpi-generic-initiator object to allow host admin link a device with an associated NUMA node. Qemu maintains this association and use this object to build the requisite GI Affinity Structure. When multiple NUMA nodes are associated with a device, it is required to create those many number of acpi-generic-initiator objects, each representing a unique device:node association. Following is one of a decoded GI affinity structure in VM ACPI SRAT. [0C8h 0200 1] Subtable Type : 05 [Generic Initiator Affinity] [0C9h 0201 1] Length : 20 [0CAh 0202 1] Reserved1 : 00 [0CBh 0203 1] Device Handle Type : 01 [0CCh 0204 4] Proximity Domain : 00000007 [0D0h 0208 16] Device Handle : 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 [0E0h 0224 4] Flags (decoded below) : 00000001 Enabled : 1 [0E4h 0228 4] Reserved2 : 00000000 [0E8h 0232 1] Subtable Type : 05 [Generic Initiator Affinity] [0E9h 0233 1] Length : 20 An admin can provide a range of acpi-generic-initiator objects, each associating a device (by providing the id through pci-dev argument) to the desired NUMA node (using the node argument). Currently, only PCI device is supported. For the grace hopper system, create a range of 8 nodes and associate that with the device using the acpi-generic-initiator object. While a configuration of less than 8 nodes per device is allowed, such configuration will prevent utilization of the feature to the fullest. The following sample creates 8 nodes per PCI device for a VM with 2 PCI devices and link them to the respecitve PCI device using acpi-generic-initiator objects: -numa node,nodeid=2 -numa node,nodeid=3 -numa node,nodeid=4 \ -numa node,nodeid=5 -numa node,nodeid=6 -numa node,nodeid=7 \ -numa node,nodeid=8 -numa node,nodeid=9 \ -device vfio-pci-nohotplug,host=0009:01:00.0,bus=pcie.0,addr=04.0,rombar=0,id=dev0 \ -object acpi-generic-initiator,id=gi0,pci-dev=dev0,node=2 \ -object acpi-generic-initiator,id=gi1,pci-dev=dev0,node=3 \ -object acpi-generic-initiator,id=gi2,pci-dev=dev0,node=4 \ -object acpi-generic-initiator,id=gi3,pci-dev=dev0,node=5 \ -object acpi-generic-initiator,id=gi4,pci-dev=dev0,node=6 \ -object acpi-generic-initiator,id=gi5,pci-dev=dev0,node=7 \ -object acpi-generic-initiator,id=gi6,pci-dev=dev0,node=8 \ -object acpi-generic-initiator,id=gi7,pci-dev=dev0,node=9 \ -numa node,nodeid=10 -numa node,nodeid=11 -numa node,nodeid=12 \ -numa node,nodeid=13 -numa node,nodeid=14 -numa node,nodeid=15 \ -numa node,nodeid=16 -numa node,nodeid=17 \ -device vfio-pci-nohotplug,host=0009:01:01.0,bus=pcie.0,addr=05.0,rombar=0,id=dev1 \ -object acpi-generic-initiator,id=gi8,pci-dev=dev1,node=10 \ -object acpi-generic-initiator,id=gi9,pci-dev=dev1,node=11 \ -object acpi-generic-initiator,id=gi10,pci-dev=dev1,node=12 \ -object acpi-generic-initiator,id=gi11,pci-dev=dev1,node=13 \ -object acpi-generic-initiator,id=gi12,pci-dev=dev1,node=14 \ -object acpi-generic-initiator,id=gi13,pci-dev=dev1,node=15 \ -object acpi-generic-initiator,id=gi14,pci-dev=dev1,node=16 \ -object acpi-generic-initiator,id=gi15,pci-dev=dev1,node=17 \ Link: https://www.nvidia.com/en-in/technologies/multi-instance-gpu [1] Cc: Jonathan Cameron <qemu-devel@nongnu.org> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Message-Id: <20240308145525.10886-2-ankita@nvidia.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12hw/i386/pc: Inline pc_cmos_init() into pc_cmos_init_late() and remove itBernhard Beschow
Now that pc_cmos_init() doesn't populate the X86MachineState::rtc attribute any longer, its duties can be merged into pc_cmos_init_late() which is called within machine_done notifier. This frees pc_piix and pc_q35 from explicit CMOS initialization. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20240303185332.1408-5-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12hw/i386/pc: Set "normal" boot device order in pc_basic_device_init()Bernhard Beschow
The boot device order may change during the lifetime of a VM. Usually, the "normal" order is set once during machine init(). However, if a user specifies `-boot once=...`, the "normal" order is overwritten by the "once" order just before machine_done, and a reset handler is registered which restores the "normal" order during the next reset. In the next patch, pc_cmos_init() will be inlined into pc_cmos_init_late() which runs during machine_done. This means that the "once" boot order would be overwritten again with the "normal" boot order -- which renders the user's choice ineffective. Fix this by setting the "normal" boot order in pc_basic_device_init() which already registers the boot_set() handler. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20240303185332.1408-4-shentey@gmail.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-03-18 08:10:10 +0000