bwlp/qemu.git/hw/acpi, branch master

hw/acpi/erst.c: Fix memory handling issues

2022-11-07T19:08:17+00:00

- Fix memset argument order: The second argument is the value, the length goes last. - Fix an integer overflow reported by Alexander Bulekov. Both issues allow the guest to overrun the host buffer allocated for the ERST memory device. Cc: Eric DeVolder Cc: qemu-stable@nongnu.org Fixes: f7e26ffa590 ("ACPI ERST: support for ACPI ERST feature") Tested-by: Alexander Bulekov Signed-off-by: Christian A. Ehrhardt Message-Id: <20221024154233.1043347-1-lk@c--e.de> Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1268 Reviewed-by: Alexander Bulekov Reviewed-by: Eric DeVolder Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

acpi: pc: vga: use AcpiDevAmlIf interface to build VGA device descriptors

2022-11-07T19:00:29+00:00

NB: We do not expect any functional change in any ACPI tables with this change. It's only a refactoring. NB2: Some targets (or1k) do not support acpi and CONFIG_ACPI is off for them. However, modules are reused between all architectures so CONFIG_ACPI is on. For those architectures, dummy stub function definitions help to resolve symbols. This change uses more of these and so it adds a couple of dummy stub definitions so that symbols for those can be resolved. Signed-off-by: Igor Mammedov Message-Id: <20221017102146.2254096-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Reviewed-by: Ani Sinha CC: Bernhard Beschow Signed-off-by: Ani Sinha Message-Id: <20221107152744.868434-1-ani@anisinha.ca>

acpi: fadt: support revision 6.0 of the ACPI specification

2022-11-07T18:12:19+00:00

Update the Fixed ACPI Description Table (FADT) to revision 6.0 of the ACPI specification adding the field "Hypervisor Vendor Identity". This field's description states the following: "64-bit identifier of hypervisor vendor. All bytes in this field are considered part of the vendor identity. These identifiers are defined independently by the vendors themselves, usually following the name of the hypervisor product. Version information should NOT be included in this field - this shall simply denote the vendor's name or identifier. Version information can be communicated through a supplemental vendor-specific hypervisor API. Firmware implementers would place zero bytes into this field, denoting that no hypervisor is present in the actual firmware." Signed-off-by: Miguel Luis Reviewed-by: Ani Sinha Message-Id: <20221011181730.10885-3-miguel.luis@oracle.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

acpi/nvdimm: Implement ACPI NVDIMM Label Methods

2022-11-02T10:56:31+00:00

Recent ACPI spec [1] has defined NVDIMM Label Methods _LS{I,R,W}, which deprecates corresponding _DSM Functions defined by PMEM _DSM Interface spec [2]. Since the semantics of the new Label Methods are almost same as old _DSM methods, the implementations here simply wrapper old ones. ASL form diff can be found in next patch of updating golden master binaries. [1] ACPI Spec v6.4, 6.5.10 NVDIMM Label Methods https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf [2] Intel PMEM _DSM Interface Spec v2.0, 3.10 Deprecated Functions https://pmem.io/documents/IntelOptanePMem_DSM_Interface-V2.0.pdf Signed-off-by: Robert Hoo Message-Id: <20220922122155.1326543-5-robert.hu@linux.intel.com> Reviewed-by: Igor Mammedov Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

acpi/nvdimm: define macro for NVDIMM Device _DSM

2022-11-02T10:56:31+00:00

Since it will be heavily used in next patch, define macro NVDIMM_DEVICE_DSM_UUID for "4309AC30-0D11-11E4-9191-0800200C9A66", which is NVDIMM device specific method uuid defined in NVDIMM _DSM interface spec, Section 3. [1] No functional changes in this patch. [1] https://pmem.io/documents/IntelOptanePMem_DSM_Interface-V2.0.pdf Signed-off-by: Robert Hoo Reviewed-by: Igor Mammedov Message-Id: <20220922122155.1326543-4-robert.hu@linux.intel.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

acpi/ssdt: Fix aml_or() and aml_and() in if clause

2022-11-02T10:56:31+00:00

In If condition, using bitwise and/or, rather than logical and/or. The result change in AML code: If (((Local6 == Zero) | (Arg0 != Local0))) ==> If (((Local6 == Zero) || (Arg0 != Local0))) If (((ObjectType (Arg3) == 0x04) & (SizeOf (Arg3) == One))) ==> If (((ObjectType (Arg3) == 0x04) && (SizeOf (Arg3) == One))) Fixes: 90623ebf603 ("nvdimm acpi: check UUID") Fixes: 4568c948066 ("nvdimm acpi: save arg3 of _DSM method") Signed-off-by: Robert Hoo Reviewed-by: Jingqi Liu Reviewed-by: Igor Mammedov Message-Id: <20220922122155.1326543-3-robert.hu@linux.intel.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

hw/acpi: Add ospm_status hook implementation for acpi-ged

2022-09-22T15:38:28+00:00

Setup an ARM virtual machine of machine virt and execute qmp "query-acpi-ospm-status" causes segmentation fault with following dumpstack: #1 0x0000aaaaab64235c in qmp_query_acpi_ospm_status (errp=errp@entry=0xfffffffff030) at ../monitor/qmp-cmds.c:312 #2 0x0000aaaaabfc4e20 in qmp_marshal_query_acpi_ospm_status (args=, ret=0xffffea4ffe90, errp=0xffffea4ffe88) at qapi/qapi-commands-acpi.c:63 #3 0x0000aaaaabff8ba0 in do_qmp_dispatch_bh (opaque=0xffffea4ffe98) at ../qapi/qmp-dispatch.c:128 #4 0x0000aaaaac02e594 in aio_bh_call (bh=0xffffe0004d80) at ../util/async.c:150 #5 aio_bh_poll (ctx=ctx@entry=0xaaaaad0f6040) at ../util/async.c:178 #6 0x0000aaaaac00bd40 in aio_dispatch (ctx=ctx@entry=0xaaaaad0f6040) at ../util/aio-posix.c:421 #7 0x0000aaaaac02e010 in aio_ctx_dispatch (source=0xaaaaad0f6040, callback=, user_data=) at ../util/async.c:320 #8 0x0000fffff76f6884 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 #9 0x0000aaaaac0452d4 in glib_pollfds_poll () at ../util/main-loop.c:297 #10 os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:320 #11 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:596 #12 0x0000aaaaab5c9e50 in qemu_main_loop () at ../softmmu/runstate.c:734 #13 0x0000aaaaab185370 in qemu_main (argc=argc@entry=47, argv=argv@entry=0xfffffffff518, envp=envp@entry=0x0) at ../softmmu/main.c:38 #14 0x0000aaaaab16f99c in main (argc=47, argv=0xfffffffff518) at ../softmmu/main.c:47 Fixes: ebb62075021a ("hw/acpi: Add ACPI Generic Event Device Support") Signed-off-by: Keqian Zhu Reviewed-by: Igor Mammedov Message-id: 20220816094957.31700-1-zhukeqian1@huawei.com Signed-off-by: Peter Maydell

acpi/nvdimm: Define trace events for NVDIMM and substitute nvdimm_debug()

2022-07-26T14:37:46+00:00

Signed-off-by: Robert Hoo Reviewed-by: Jingqi Liu Message-Id: <20220704085852.330005-1-robert.hu@linux.intel.com> Reviewed-by: Igor Mammedov Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

trivial typos: namesapce

2022-06-28T09:06:44+00:00

'namespace' is misspelled in a bunch of places. Signed-off-by: Dr. David Alan Gilbert Reviewed-by: Klaus Jensen Message-Id: <20220614104045.85728-3-dgilbert@redhat.com> Signed-off-by: Laurent Vivier

hw/acpi: Make the PCI hot-plug aware of SR-IOV

2022-06-23T21:24:29+00:00

PCI device capable of SR-IOV support is a new, still-experimental feature with only a single working example of the Nvme device. This patch in an attempt to fix a double-free problem when a SR-IOV-capable Nvme device is hot-unplugged in the following scenario: Qemu CLI: --------- -device pcie-root-port,slot=0,id=rp0 -device nvme-subsys,id=subsys0 -device nvme,id=nvme0,bus=rp0,serial=deadbeef,subsys=subsys0,sriov_max_vfs=1,sriov_vq_flexible=2,sriov_vi_flexible=1 Guest OS: --------- sudo nvme virt-mgmt /dev/nvme0 -c 0 -r 1 -a 1 -n 0 sudo nvme virt-mgmt /dev/nvme0 -c 0 -r 0 -a 1 -n 0 echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset sleep 1 echo 1 > /sys/bus/pci/devices/0000:01:00.0/sriov_numvfs nvme virt-mgmt /dev/nvme0 -c 1 -r 1 -a 8 -n 1 nvme virt-mgmt /dev/nvme0 -c 1 -r 0 -a 8 -n 2 nvme virt-mgmt /dev/nvme0 -c 1 -r 0 -a 9 -n 0 sleep 2 echo 01:00.1 > /sys/bus/pci/drivers/nvme/bind Qemu monitor: ------------- device_del nvme0 Explanation of the problem and the proposed solution: 1) The current SR-IOV implementation assumes it’s the PhysicalFunction that creates and deletes VirtualFunctions. 2) It’s a design decision (the Nvme device at least) for the VFs to be of the same class as PF. Effectively, they share the dc->hotpluggable value. 3) When a VF is created, it’s added as a child node to PF’s PCI bus slot. 4) Monitor/device_del triggers the ACPI mechanism. The implementation is not aware of SR/IOV and ejects PF’s PCI slot, directly unrealizing all hot-pluggable (!acpi_pcihp_pc_no_hotplug) children nodes. 5) VFs are unrealized directly, and it doesn’t work well with (1). SR/IOV structures are not updated, so when it’s PF’s turn to be unrealized, it works on stale pointers to already-deleted VFs. The proposed fix is to make the PCI ACPI code aware of SR/IOV. Signed-off-by: Łukasz Gieryk Acked-by: Michael S. Tsirkin Reviewed-by: Michael S. Tsirkin Signed-off-by: Klaus Jensen