aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
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>
2024-03-12hw/i386/pc: Avoid one use of the current_machine globalBernhard Beschow
The RTC can be accessed through the X86 machine instance, so rather than passing the RTC it's possible to pass the machine state instead. This avoids pc_boot_set() from having to access the current_machine global. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20240303185332.1408-3-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-03-12hw/i386/pc: Remove "rtc_state" link againBernhard Beschow
Commit 99e1c1137b6f "hw/i386/pc: Populate RTC attribute directly" made linking the "rtc_state" property unnecessary and removed it. Commit 84e945aad2d0 "vl, pc: turn -no-fd-bootchk into a machine property" accidently reintroduced the link. Remove it again since it is not needed. Fixes: 84e945aad2d0 "vl, pc: turn -no-fd-bootchk into a machine property" Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20240303185332.1408-2-shentey@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-03-12Revert "hw/i386/pc: Confine system flash handling to pc_sysfw"Bernhard Beschow
Specifying the property `-M pflash0` results in a regression: qemu-system-x86_64: Property 'pc-q35-9.0-machine.pflash0' not found Revert the change for now until a solution is found. This reverts commit 6f6ad2b24582593d8feb00434ce2396840666227. Reported-by: Volker Rümelin <vr_qemu@t-online.de> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20240226215909.30884-3-shentey@gmail.com> Tested-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12Revert "hw/i386/pc_sysfw: Inline pc_system_flash_create() and remove it"Bernhard Beschow
Commit 6f6ad2b24582 "hw/i386/pc: Confine system flash handling to pc_sysfw" causes a regression when specifying the property `-M pflash0` in the PCI PC machines: qemu-system-x86_64: Property 'pc-q35-9.0-machine.pflash0' not found In order to revert the commit, the commit below must be reverted first. This reverts commit cb05cc16029bb0a61ac5279ab7b3b90dcf2aa69f. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20240226215909.30884-2-shentey@gmail.com> Tested-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12pc: q35: Bump max_cpus to 4096 vcpusAni Sinha
Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to allow up to 4096 vCPUs") Linux kernel can support upto a maximum number of 4096 vcpus when MAXSMP is enabled in the kernel. At present, QEMU has been tested to correctly boot a linux guest with 4096 vcpus using the current edk2 upstream master branch that has the fixes corresponding to the following two PRs: https://github.com/tianocore/edk2/pull/5410 https://github.com/tianocore/edk2/pull/5418 The changes merged into edk2 with the above PRs will be in the upcoming 2024-05 release. With current seabios firmware, it boots fine with 4096 vcpus already. So bump up the value max_cpus to 4096 for q35 machines versions 9 and newer. Q35 machines versions 8.2 and older continue to support 1024 maximum vcpus as before for compatibility reasons. If KVM is not able to support the specified number of vcpus, QEMU would return the following error messages: $ ./qemu-system-x86_64 -cpu host -accel kvm -machine q35 -smp 1728 qemu-system-x86_64: -accel kvm: warning: Number of SMP cpus requested (1728) exceeds the recommended cpus supported by KVM (12) qemu-system-x86_64: -accel kvm: warning: Number of hotpluggable cpus requested (1728) exceeds the recommended cpus supported by KVM (12) Number of SMP cpus requested (1728) exceeds the maximum cpus supported by KVM (1024) Cc: Daniel P. Berrangé <berrange@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Julia Suvorova <jusual@redhat.com> Cc: kraxel@redhat.com Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Ani Sinha <anisinha@redhat.com> Message-Id: <20240228143351.3967-1-anisinha@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12hw/pci: Always call pcie_sriov_pf_reset()Akihiko Odaki
Call pcie_sriov_pf_reset() from pci_do_device_reset() just as we do for msi_reset() and msix_reset() to prevent duplicating code for each SR-IOV PF. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20240228-reuse-v8-5-282660281e60@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com>
2024-03-12pcie_sriov: Do not reset NumVFs after disabling VFsAkihiko Odaki
The spec does not NumVFs is reset after disabling VFs except when resetting the PF. Clearing it is guest visible and out of spec, even though Linux doesn't rely on this value being preserved, so we never noticed. Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization (SR/IOV)") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20240228-reuse-v8-4-282660281e60@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12pcie_sriov: Reset SR-IOV extended capabilityAkihiko Odaki
pcie_sriov_pf_disable_vfs() is called when resetting the PF, but it only disables VFs and does not reset SR-IOV extended capability, leaking the state and making the VF Enable register inconsistent with the actual state. Replace pcie_sriov_pf_disable_vfs() with pcie_sriov_pf_reset(), which does not only disable VFs but also resets the capability. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20240228-reuse-v8-3-282660281e60@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com>
2024-03-12pcie_sriov: Validate NumVFsAkihiko Odaki
The guest may write NumVFs greater than TotalVFs and that can lead to buffer overflow in VF implementations. Cc: qemu-stable@nongnu.org Fixes: CVE-2024-26327 Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization (SR/IOV)") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20240228-reuse-v8-2-282660281e60@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com>
2024-03-12hw/nvme: Use pcie_sriov_num_vfs()Akihiko Odaki
nvme_sriov_pre_write_ctrl() used to directly inspect SR-IOV configurations to know the number of VFs being disabled due to SR-IOV configuration writes, but the logic was flawed and resulted in out-of-bound memory access. It assumed PCI_SRIOV_NUM_VF always has the number of currently enabled VFs, but it actually doesn't in the following cases: - PCI_SRIOV_NUM_VF has been set but PCI_SRIOV_CTRL_VFE has never been. - PCI_SRIOV_NUM_VF was written after PCI_SRIOV_CTRL_VFE was set. - VFs were only partially enabled because of realization failure. It is a responsibility of pcie_sriov to interpret SR-IOV configurations and pcie_sriov does it correctly, so use pcie_sriov_num_vfs(), which it provides, to get the number of enabled VFs before and after SR-IOV configuration writes. Cc: qemu-stable@nongnu.org Fixes: CVE-2024-26328 Fixes: 11871f53ef8e ("hw/nvme: Add support for the Virtualization Management command") Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20240228-reuse-v8-1-282660281e60@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12Implement SMBIOS type 9 v2.6Felix Wu
Signed-off-by: Felix Wu <flwu@google.com> Signed-off-by: Nabih Estefan <nabihestefan@google.com> Message-Id: <20240221170027.1027325-3-nabihestefan@google.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12Implement base of SMBIOS type 9 descriptor.Felix Wu
Version 2.1+. Signed-off-by: Felix Wu <flwu@google.com> Signed-off-by: Nabih Estefan <nabihestefan@google.com> Message-Id: <20240221170027.1027325-2-nabihestefan@google.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12hw/intc: Check @errp to handle the error of IOAPICCommonClass.realize()Zhao Liu
IOAPICCommonClass implements its own private realize(), and this private realize() allows error. Since IOAPICCommonClass.realize() returns void, to check the error, dereference @errp with ERRP_GUARD(). Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20240223085653.1255438-8-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-03-12hw/vfio/iommufd: Fix missing ERRP_GUARD() in iommufd_cdev_getfd()Zhao Liu
As the comment in qapi/error, dereferencing @errp requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: * - It must not be dereferenced, because it may be null. ... * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. * * Using it when it's not needed is safe, but please avoid cluttering * the source with useless code. But in iommufd_cdev_getfd(), @errp is dereferenced without ERRP_GUARD(): if (*errp) { error_prepend(errp, VFIO_MSG_PREFIX, path); } Currently, since vfio_attach_device() - the caller of iommufd_cdev_getfd() - is always called in DeviceClass.realize() context and doesn't get the NULL @errp parameter, iommufd_cdev_getfd() hasn't triggered the bug that dereferencing the NULL @errp. To follow the requirement of @errp, add missing ERRP_GUARD() in iommufd_cdev_getfd(). Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20240223085653.1255438-7-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12hw/pci-bridge/cxl_upstream: Fix missing ERRP_GUARD() in cxl_usp_realize()Zhao Liu
As the comment in qapi/error, dereferencing @errp requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: * - It must not be dereferenced, because it may be null. ... * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. * * Using it when it's not needed is safe, but please avoid cluttering * the source with useless code. But in cxl_usp_realize(), @errp is dereferenced without ERRP_GUARD(): cxl_doe_cdat_init(cxl_cstate, errp); if (*errp) { goto err_cap; } Here we check *errp, because cxl_doe_cdat_init() returns void. And since cxl_usp_realize() - as a PCIDeviceClass.realize() method - doesn't get the NULL @errp parameter, it hasn't triggered the bug that dereferencing the NULL @errp. To follow the requirement of @errp, add missing ERRP_GUARD() in cxl_usp_realize(). Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20240223085653.1255438-6-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
2024-03-12hw/misc/xlnx-versal-trng: Check returned bool in trng_prop_fault_event_set()Zhao Liu
As the comment in qapi/error, dereferencing @errp requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: * - It must not be dereferenced, because it may be null. ... * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. * * Using it when it's not needed is safe, but please avoid cluttering * the source with useless code. But in trng_prop_fault_event_set, @errp is dereferenced without ERRP_GUARD(): visit_type_uint32(v, name, events, errp); if (*errp) { return; } Currently, since trng_prop_fault_event_set() doesn't get the NULL @errp parameter as a "set" method of object property, it hasn't triggered the bug that dereferencing the NULL @errp. And since visit_type_uint32() returns bool, check the returned bool directly instead of dereferencing @errp, then we needn't the add missing ERRP_GUARD(). Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Message-Id: <20240223085653.1255438-5-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-03-12hw/mem/cxl_type3: Fix missing ERRP_GUARD() in ct3_realize()Zhao Liu
As the comment in qapi/error, dereferencing @errp requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: * - It must not be dereferenced, because it may be null. ... * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. * * Using it when it's not needed is safe, but please avoid cluttering * the source with useless code. But in ct3_realize(), @errp is dereferenced without ERRP_GUARD(): cxl_doe_cdat_init(cxl_cstate, errp); if (*errp) { goto err_free_special_ops; } Here we check *errp, because cxl_doe_cdat_init() returns void. And ct3_realize() - as a PCIDeviceClass.realize() method - doesn't get the NULL @errp parameter, it hasn't triggered the bug that dereferencing the NULL @errp. To follow the requirement of @errp, add missing ERRP_GUARD() in ct3_realize(). Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20240223085653.1255438-4-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-03-12hw/display/macfb: Fix missing ERRP_GUARD() in macfb_nubus_realize()Zhao Liu
As the comment in qapi/error, dereferencing @errp requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: * - It must not be dereferenced, because it may be null. ... * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. * * Using it when it's not needed is safe, but please avoid cluttering * the source with useless code. But in macfb_nubus_realize(), @errp is dereferenced without ERRP_GUARD(): ndc->parent_realize(dev, errp); if (*errp) { return; } Here we check *errp, because the ndc->parent_realize(), as a DeviceClass.realize() callback, returns void. And since macfb_nubus_realize(), also as a DeviceClass.realize(), doesn't get the NULL @errp parameter, it hasn't triggered the bug that dereferencing the NULL @errp. To follow the requirement of @errp, add missing ERRP_GUARD() in macfb_nubus_realize(). Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20240223085653.1255438-3-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12hw/cxl/cxl-host: Fix missing ERRP_GUARD() in cxl_fixed_memory_window_config()Zhao Liu
As the comment in qapi/error, dereferencing @errp requires ERRP_GUARD(): * = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: * - It must not be dereferenced, because it may be null. ... * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal. * * Using it when it's not needed is safe, but please avoid cluttering * the source with useless code. But in cxl_fixed_memory_window_config(), @errp is dereferenced in 2 places without ERRP_GUARD(): fw->enc_int_ways = cxl_interleave_ways_enc(fw->num_targets, errp); if (*errp) { return; } and fw->enc_int_gran = cxl_interleave_granularity_enc(object->interleave_granularity, errp); if (*errp) { return; } For the above 2 places, we check "*errp", because neither function returns a suitable error code. And since machine_set_cfmw() - the caller of cxl_fixed_memory_window_config() - doesn't get the NULL @errp parameter as the "set" method of object property, cxl_fixed_memory_window_config() hasn't triggered the bug that dereferencing the NULL @errp. To follow the requirement of @errp, add missing ERRP_GUARD() in cxl_fixed_memory_window_config(). Suggested-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20240223085653.1255438-2-zhao1.liu@linux.intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-03-12hw/virtio: Add support for VDPA network simulation devicesHao Chen
This patch adds support for VDPA network simulation devices. The device is developed based on virtio-net and tap backend, and supports hardware live migration function. For more details, please refer to "docs/system/devices/vdpa-net.rst" Signed-off-by: Hao Chen <chenh@yusur.tech> Message-Id: <20240221073802.2888022-1-chenh@yusur.tech> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12hw/virtio: check owner for removing objectsAlbert Esteve
Shared objects lack spoofing protection. For VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE messages received by the vhost-user interface, any backend was allowed to remove entries from the shared table just by knowing the UUID. Only the owner of the entry shall be allowed to removed their resources from the table. To fix that, add a check for all *SHARED_OBJECT_REMOVE messages received. A vhost device can only remove TYPE_VHOST_DEV entries that are owned by them, otherwise skip the removal, and inform the device that the entry has not been removed in the answer. Signed-off-by: Albert Esteve <aesteve@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20240219143423.272012-2-aesteve@redhat.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-03-12hw/audio/virtio-sound: return correct command response sizeVolker Rümelin
The payload size returned by command VIRTIO_SND_R_PCM_INFO is wrong. The code in process_cmd() assumes that all commands return only a virtio_snd_hdr payload, but some commands like VIRTIO_SND_R_PCM_INFO may return an additional payload. Add a zero initialized payload_size variable to struct virtio_snd_ctrl_command to allow for additional payloads. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-Id: <20240218083351.8524-1-vr_qemu@t-online.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12hw/pci-bridge/pxb-cxl: Drop RAS capability from host bridge.Jonathan Cameron
This CXL component isn't allowed to have a RAS capability. Whilst this should be harmless as software is not expected to look here, good to clean it up. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20240215155206.2736-1-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12vdpa: trace skipped memory sectionsEugenio Pérez
Sometimes, certain parts are not being skipped in vhost_vdpa_listener_region_del, but they are skipped in vhost_vdpa_listener_region_add, or vice versa. The vhost-vdpa code expects all parts to maintain their properties, so we're adding a trace to help with debugging when any part is skipped. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20240215103616.330518-3-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12vdpa: stash memory region properties in varsEugenio Pérez
Next changes uses this variables, so avoid call repeatedly to memory region functions. No functional change intended. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20240215103616.330518-2-eperezma@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12pcie: Support PCIe Gen5/Gen6 link speedsLukas Stockner
This patch extends the PCIe link speed option so that slots can be configured as supporting 32GT/s (Gen5) or 64GT/s (Gen5) speeds. This is as simple as setting the appropriate bit in LnkCap2 and the appropriate value in LnkCap and LnkCtl2. Signed-off-by: Lukas Stockner <lstockner@genesiscloud.com> Message-Id: <20240215012326.3272366-1-lstockner@genesiscloud.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12vdpa: fix network breakage after cancelling migrationSi-Wei Liu
Fix an issue where cancellation of ongoing migration ends up with no network connectivity. When canceling migration, SVQ will be switched back to the passthrough mode, but the right call fd is not programed to the device and the svq's own call fd is still used. At the point of this transitioning period, the shadow_vqs_enabled hadn't been set back to false yet, causing the installation of call fd inadvertently bypassed. Message-Id: <1707910082-10243-13-git-send-email-si-wei.liu@oracle.com> Fixes: a8ac88585da1 ("vhost: Add Shadow VirtQueue call forwarding capabilities") Cc: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12vdpa: add vhost_vdpa_set_dev_vring_base trace for svq modeSi-Wei Liu
For better debuggability and observability. Message-Id: <1707910082-10243-8-git-send-email-si-wei.liu@oracle.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12vdpa: add vhost_vdpa_get_vring_base trace for svq modeSi-Wei Liu
For better debuggability and observability. Message-Id: <1707910082-10243-7-git-send-email-si-wei.liu@oracle.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12vdpa: factor out vhost_vdpa_last_devSi-Wei Liu
Generalize duplicated condition check for the last vq of vdpa device to a common function. Message-Id: <1707910082-10243-4-git-send-email-si-wei.liu@oracle.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-03-12Merge tag 'nvme-next-pull-request' of https://gitlab.com/birkelund/qemu into ↵Peter Maydell
staging hw/nvme updates # -----BEGIN PGP SIGNATURE----- # # iQEzBAABCgAdFiEEUigzqnXi3OaiR2bATeGvMW1PDekFAmXwj+wACgkQTeGvMW1P # DelOsAf+Jg51zf3vtWpe4MS/WtULjSr5GtnXMJ5hkHS0WdKOiLW3P+pUZXbsohmh # faVlYeCWptF1CFGfxBf4Trc7XzJy8J6W1YJEofs/07hIAnazo9pwk5shoVu4oiex # HVsBg7/9y7DuiEEg1MRvVvW895cP60WmG1AqU63SYwrVgxZ51ZH0XNuyRhQeYC/6 # OSXJ3FDYu2iJQ58uEzGEwv8vhskIpEFTdz0J6gQVxIdzFBbuk87VgZo6pqwgfMBm # /65K85TgFBT4SASc7a2iSUv+iAqSCA6Jdy0VWxCYCikiv5nuPCMCrlbvqcVp+i2B # GKtgfFXhtgepxx6jmYd03EkRjCrxUA== # =W3gg # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 17:25:00 GMT # gpg: using RSA key 522833AA75E2DCE6A24766C04DE1AF316D4F0DE9 # gpg: Good signature from "Klaus Jensen <its@irrelevant.dk>" [full] # gpg: aka "Klaus Jensen <k.jensen@samsung.com>" [full] # Primary key fingerprint: DDCA 4D9C 9EF9 31CC 3468 4272 63D5 6FC5 E55D A838 # Subkey fingerprint: 5228 33AA 75E2 DCE6 A247 66C0 4DE1 AF31 6D4F 0DE9 * tag 'nvme-next-pull-request' of https://gitlab.com/birkelund/qemu: hw/nvme: add machine compatibility parameter to enable msix exclusive bar hw/nvme: generalize the mbar size helper hw/nvme: Add NVMe NGUID property MAINTAINERS: add Jesper as reviewer on hw/nvme hw/nvme: fix invalid check on mcl hw/nvme: separate 'serial' property for VFs Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-03-12Merge tag 'pull-xen-20240312' of ↵Peter Maydell
https://xenbits.xen.org/git-http/people/aperard/qemu-dm into staging Xen queue: * In Xen PCI passthrough, emulate multifunction bit. * Fix in Xen mapcache. * Improve performance of kernel+initrd loading in an Xen HVM Direct Kernel Boot scenario. # -----BEGIN PGP SIGNATURE----- # # iQEzBAABCgAdFiEE+AwAYwjiLP2KkueYDPVXL9f7Va8FAmXwZbwACgkQDPVXL9f7 # Va+PhQgAusZBhy3b0hOCCoqC/1ffCE5J2JxUTnN3zN/2FSOe8/kqQYqt4Zk3vi2e # Eq8FbGupU357eoJSz0gTEPKQ8y+FVBCmFKEHM1PS54TW1yUZchQg4RmlII6+Psoj # 7u+qC1RqZu/ZQ9f1QZd8YDJ5oVOkfAZYwq5BkWVS6h5gJiQTSkekAXlMNOQBZxz4 # 48fzpokatiJBbyaBGEm6YKEOwkYG76eHhxB4SC0Rgx6zW+EDQpX0s/Lg19SXnj2C # UOueiPod1GkE+iH6dQFJUSbsnrkAtJZf253bs3BQnoChGiqQLuXn4jC79ffjPzHI # AKP2+u+bSJ+8C1SdPuoJN6sJIZmOfA== # =FZ2n # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 14:25:00 GMT # gpg: using RSA key F80C006308E22CFD8A92E7980CF5572FD7FB55AF # gpg: Good signature from "Anthony PERARD <anthony.perard@gmail.com>" [marginal] # gpg: aka "Anthony PERARD <anthony.perard@citrix.com>" [marginal] # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 5379 2F71 024C 600F 778A 7161 D8D5 7199 DF83 42C8 # Subkey fingerprint: F80C 0063 08E2 2CFD 8A92 E798 0CF5 572F D7FB 55AF * tag 'pull-xen-20240312' of https://xenbits.xen.org/git-http/people/aperard/qemu-dm: i386: load kernel on xen using DMA xen: Drop out of coroutine context xen_invalidate_map_cache_entry xen/pt: Emulate multifunction bit in header type Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-03-12Merge tag 'ui-pull-request' of https://gitlab.com/marcandre.lureau/qemu into ↵Peter Maydell
staging display/ui: pending fixes - ui/vnc: Respect bound console - ui/dbus: optimize a bit message queuing - virtio-gpu: fix blob scanout post-load # -----BEGIN PGP SIGNATURE----- # # iQJQBAABCAA6FiEEh6m9kz+HxgbSdvYt2ujhCXWWnOUFAmXwYCYcHG1hcmNhbmRy # ZS5sdXJlYXVAcmVkaGF0LmNvbQAKCRDa6OEJdZac5bv9D/9J1g76mYND+ad++d+G # YiewXtHVwrHm9g+TxUdWXaBcDFy+uFtGpwIBtYN76YjSSL47li74V7sQTZ2FQVys # Y8W61xBzDoAcCLV7/m48WW/mov2+TtyUFYIC3ZOBFS6Ol5aiJ8uurJa11h2WTacq # tQKlK5g//Yv0H0cxn1cYMqRFdsko3H2hSmYz36QuPWfxivC2VeMnN/iTSGfiVSb+ # hTkOdRu+5qmt3mbbYo0Z6YpvjhLqSLob6n29+P7/QlwrQxP+A/JSS4FrAHryXzvm # qZ/wRsPmThjwpnt3ZV9AapagQ7908FRmh1EhyAxrWq2G8QGK/XvJ/JPwBOgZGEiy # W48N5FQhdQUkxkVpkmQVpGhJFAzclqJh/duZiBtixw+25Md6DG04OwHy9k7qCph7 # qj2BZuaSafVcSE0JEG78bt5YHAO3Joyfjf7Jhb0Tqvn2kbv94tCTGtUIH6ngYv4Z # r0vTmlDr7pe1xaa9HeFpaopckvj4uQhlcMHnrETnUtcdWKE5SaBlgNsIwHlNlKZ6 # wmUIMKymXNRIiCZrf2xxJr7PeZ8FJgTlHCy9poSJRwpZDKHaZQMecklELx+jECuU # DPhAmTPTZjCKiXGCI+KlL6nDy/H7zA6boCMO2QpKVk0ehviWOQZvu94srTJL5nz/ # RX+rwGbf3+8LfIFJmLcQCD5qag== # =oY0A # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 14:01:10 GMT # gpg: using RSA key 87A9BD933F87C606D276F62DDAE8E10975969CE5 # gpg: issuer "marcandre.lureau@redhat.com" # gpg: Good signature from "Marc-André Lureau <marcandre.lureau@redhat.com>" [full] # gpg: aka "Marc-André Lureau <marcandre.lureau@gmail.com>" [full] # Primary key fingerprint: 87A9 BD93 3F87 C606 D276 F62D DAE8 E109 7596 9CE5 * tag 'ui-pull-request' of https://gitlab.com/marcandre.lureau/qemu: virtio-gpu: fix scanout migration post-load virtio-gpu: remove needless condition ui/dbus: filter out pending messages when scanout ui/dbus: factor out sending a scanout ui/vnc: Respect bound console Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-03-12Merge tag 'pull-request-2024-03-12' of https://gitlab.com/thuth/qemu into ↵Peter Maydell
staging * Add missing ERRP_GUARD() statements in functions that need it * Prefer fast cpu_env() over slower CPU QOM cast macro # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmXwPhYRHHRodXRoQHJl # ZGhhdC5jb20ACgkQLtnXdP5wLbWHvBAAgKx5LHFjz3xREVA+LkDTQ49mz0lK3s32 # SGvNlIHjiaDGVttVYhVC4sinBWUruG4Lyv/2QN72OJBzn6WUsEUQE3KPH1d7Y3/s # wS9X7mj70n4kugWJqeIJP5AXSRasHmWoQ4QJLVQRJd6+Eb9jqwep0x7bYkI1de6D # bL1Q7bIfkFeNQBXaiPWAm2i+hqmT4C1r8HEAGZIjAsMFrjy/hzBEjNV+pnh6ZSq9 # Vp8BsPWRfLU2XHm4WX0o8d89WUMAfUGbVkddEl/XjIHDrUD+Zbd1HAhLyfhsmrnE # jXIwSzm+ML1KX4MoF5ilGtg8Oo0gQDEBy9/xck6G0HCm9lIoLKlgTxK9glr2vdT8 # yxZmrM9Hder7F9hKKxmb127xgU6AmL7rYmVqsoQMNAq22D6Xr4UDpgFRXNk2/wO6 # zZZBkfZ4H4MpZXbd/KJpXvYH5mQA4IpkOy8LJdE+dbcHX7Szy9ksZdPA+Z10hqqf # zqS13qTs3abxymy2Q/tO3hPKSJCk1+vCGUkN60Wm+9VoLWGoU43qMc7gnY/pCS7m # 0rFKtvfwFHhokX1orK0lP/ppVzPv/5oFIeK8YDY9if+N+dU2LCwVZHIuf2/VJPRq # wmgH2vAn3JDoRKPxTGX9ly6AMxuZaeP92qBTOPap0gDhihYzIpaCq9ecEBoTakI7 # tdFhV0iRr08= # =NiP4 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 11:35:50 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-12' of https://gitlab.com/thuth/qemu: (55 commits) user: Prefer fast cpu_env() over slower CPU QOM cast macro target/xtensa: Prefer fast cpu_env() over slower CPU QOM cast macro target/tricore: Prefer fast cpu_env() over slower CPU QOM cast macro target/sparc: Prefer fast cpu_env() over slower CPU QOM cast macro target/sh4: Prefer fast cpu_env() over slower CPU QOM cast macro target/rx: Prefer fast cpu_env() over slower CPU QOM cast macro target/ppc: Prefer fast cpu_env() over slower CPU QOM cast macro target/openrisc: Prefer fast cpu_env() over slower CPU QOM cast macro target/nios2: Prefer fast cpu_env() over slower CPU QOM cast macro target/mips: Prefer fast cpu_env() over slower CPU QOM cast macro target/microblaze: Prefer fast cpu_env() over slower CPU QOM cast macro target/m68k: Prefer fast cpu_env() over slower CPU QOM cast macro target/loongarch: Prefer fast cpu_env() over slower CPU QOM cast macro target/i386/hvf: Use CPUState typedef target/hexagon: Prefer fast cpu_env() over slower CPU QOM cast macro target/cris: Prefer fast cpu_env() over slower CPU QOM cast macro target/avr: Prefer fast cpu_env() over slower CPU QOM cast macro target/alpha: Prefer fast cpu_env() over slower CPU QOM cast macro target: Replace CPU_GET_CLASS(cpu -> obj) in cpu_reset_hold() handler bulk: Call in place single use cpu_env() ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-03-13spapr: nested: Introduce cap-nested-papr for Nested PAPR APIHarsh Prateek Bora
Introduce a SPAPR capability cap-nested-papr which enables nested PAPR API for nested guests. This new API is to enable support for KVM on PowerVM and the support in Linux kernel has already merged upstream. Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-03-13spapr: nested: Introduce H_GUEST_RUN_VCPU hcall.Harsh Prateek Bora
The H_GUEST_RUN_VCPU hcall is used to start execution of a Guest VCPU. The Hypervisor will update the state of the Guest VCPU based on the input buffer, restore the saved Guest VCPU state, and start its execution. The Guest VCPU can stop running for numerous reasons including HCALLs, hypervisor exceptions, or an outstanding Host Partition Interrupt. The reason that the Guest VCPU stopped running is communicated through R4 and the output buffer will be filled in with any relevant state. Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-03-13spapr: nested: Use correct source for parttbl info for nested PAPR API.Harsh Prateek Bora
For nested PAPR API, we use SpaprMachineStateNestedGuest struct to store partition table info, use the same in spapr_get_pate_nested() via helper. Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-03-13spapr: nested: Introduce H_GUEST_[GET|SET]_STATE hcalls.Harsh Prateek Bora
Introduce the nested PAPR hcalls: - H_GUEST_GET_STATE which is used to get state of a nested guest or a guest VCPU. The value field for each element in the request is destination to be updated to reflect current state on success. - H_GUEST_SET_STATE which is used to modify the state of a guest or a guest VCPU. On success, guest (or its VCPU) state shall be updated as per the value field for the requested element(s). Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-03-13spapr: nested: Initialize the GSB elements lookup table.Harsh Prateek Bora
Nested PAPR API provides a standard Guest State Buffer (GSB) format with unique IDs for each guest state element for which get/set state is supported by the API. Some of the elements are read-only and/or guest-wide. Introducing additional required GSB elements and helper routines for state exchange of each of the nested guest state elements for which get/set state should be supported by the API. [amachhiw: set the PCR whenever logical PVR is set] Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Signed-off-by: Amit Machhiwal <amachhiw@linux.vnet.ibm.com> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-03-13spapr: nested: Extend nested_ppc_state for nested PAPR APIHarsh Prateek Bora
Currently, nested_ppc_state stores a certain set of registers and works with nested_[load|save]_state() for state transfer as reqd for nested-hv API. Extending these with additional registers state as reqd for nested PAPR API. Acked-by: Nicholas Piggin <npiggin@gmail.com> Suggested-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-03-13spapr: nested: Introduce H_GUEST_CREATE_VCPU hcall.Harsh Prateek Bora
Introduce the nested PAPR hcall H_GUEST_CREATE_VCPU which is used to create and initialize the specified VCPU resource for the previously created guest. Each guest can have multiple VCPUs upto max 2048. All VCPUs for a guest gets deallocated on guest delete. Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-03-13spapr: nested: Introduce H_GUEST_[CREATE|DELETE] hcalls.Harsh Prateek Bora
Introduce the nested PAPR hcalls: - H_GUEST_CREATE which is used to create and allocate resources for nested guest being created. - H_GUEST_DELETE which is used to delete and deallocate resources for the nested guest being deleted. It also supports deleting all nested guests at once using a deleteAll flag. Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-03-13spapr: nested: Introduce H_GUEST_[GET|SET]_CAPABILITIES hcalls.Harsh Prateek Bora
Introduce the nested PAPR hcalls: - H_GUEST_GET_CAPABILITIES which is used to query the capabilities of the API and the L2 guests it provides. - H_GUEST_SET_CAPABILITIES which is used to set the Guest API capabilities that the Host Partition supports and may use. [amachhiw: support for p9 compat mode and return register bug fixes] Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Amit Machhiwal <amachhiw@linux.vnet.ibm.com> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-03-13spapr: nested: keep nested-hv related code restricted to its API.Harsh Prateek Bora
spapr_exit_nested and spapr_get_pate_nested_hv contains code which is specific to nested-hv API. Isolating code flows based on API helps extending it to be used with different API as well. Suggested-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-03-13spapr: nested: Introduce SpaprMachineStateNested to store related info.Harsh Prateek Bora
Currently, nested_ptcr is being used by existing nested-hv API to store nested guest related info. This need to be organised to extend support for the nested PAPR API which would need to store additional info related to nested guests in next series of patches. Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-03-13spapr: nested: move nested part of spapr_get_pate into spapr_nested.cHarsh Prateek Bora
Most of the nested code has already been moved to spapr_nested.c This logic inside spapr_get_pate is related to nested guests and better suited for spapr_nested.c, hence moving there. Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-03-13spapr: nested: register nested-hv api hcalls only for cap-nested-hvHarsh Prateek Bora
Since cap-nested-hv is an optional capability, it makes sense to register api specfic hcalls only when respective capability is enabled. This requires to introduce a new API to unregister hypercalls to maintain sanity across guest reboot since caps are re-applied across reboots and re-registeration of hypercalls would hit assert otherwise. Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
2024-03-13ppc/pnv: Improve pervasive topology calculation for big-coreCaleb Schlossin
Big (SMT8) cores have a complicated function to map the core, thread ID to pervasive topology (PIR). Fix this for power8, power9, and power10. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Caleb Schlossin <calebs@linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-14 17:13:57 +0000