summary refs log tree commit diff stats
path: root/docs/sphinx/kerneldoc.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2020-06-26osdep: Make MIN/MAX evaluate arguments only onceEric Blake7-23/+63
I'm not aware of any immediate bugs in qemu where a second runtime evaluation of the arguments to MIN() or MAX() causes a problem, but proactively preventing such abuse is easier than falling prey to an unintended case down the road. At any rate, here's the conversation that sparked the current patch: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg05718.html Update the MIN/MAX macros to only evaluate their argument once at runtime; this uses typeof(1 ? (a) : (b)) to ensure that we are promoting the temporaries to the same type as the final comparison (we have to trigger type promotion, as typeof(bitfield) won't compile; and we can't use typeof((a) + (b)) or even typeof((a) + 0), as some of our uses of MAX are on void* pointers where such addition is undefined). However, we are unable to work around gcc refusing to compile ({}) in a constant context (such as the array length of a static variable), even when only used in the dead branch of a __builtin_choose_expr(), so we have to provide a second macro pair MIN_CONST and MAX_CONST for use when both arguments are known to be compile-time constants and where the result must also be usable as a constant; this second form evaluates arguments multiple times but that doesn't matter for constants. By using a void expression as the expansion if a non-constant is presented to this second form, we can enlist the compiler to ensure the double evaluation is not attempted on non-constants. Alas, as both macros now rely on compiler intrinsics, they are no longer usable in preprocessor #if conditions; those will just have to be open-coded or the logic rewritten into #define or runtime 'if' conditions (but where the compiler dead-code-elimination will probably still apply). I tested that both gcc 10.1.1 and clang 10.0.0 produce errors for all forms of macro mis-use. As the errors can sometimes be cryptic, I'm demonstrating the gcc output: Use of MIN when MIN_CONST is needed: In file included from /home/eblake/qemu/qemu-img.c:25: /home/eblake/qemu/include/qemu/osdep.h:249:5: error: braced-group within expression allowed only inside a function 249 | ({ \ | ^ /home/eblake/qemu/qemu-img.c:92:12: note: in expansion of macro ‘MIN’ 92 | char array[MIN(1, 2)] = ""; | ^~~ Use of MIN_CONST when MIN is needed: /home/eblake/qemu/qemu-img.c: In function ‘is_allocated_sectors’: /home/eblake/qemu/qemu-img.c:1225:15: error: void value not ignored as it ought to be 1225 | i = MIN_CONST(i, n); | ^ Use of MIN in the preprocessor: In file included from /home/eblake/qemu/accel/tcg/translate-all.c:20: /home/eblake/qemu/accel/tcg/translate-all.c: In function ‘page_check_range’: /home/eblake/qemu/include/qemu/osdep.h:249:6: error: token "{" is not valid in preprocessor expressions 249 | ({ \ | ^ Fix the resulting callsites that used #if or computed a compile-time constant min or max to use the new macros. cpu-defs.h is interesting, as CPU_TLB_DYN_MAX_BITS is sometimes used as a constant and sometimes dynamic. It may be worth improving glib's MIN/MAX definitions to be saner, but that is a task for another day. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200625162602.700741-1-eblake@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26target/i386: Add notes for versioned CPU modelsTao Xu1-0/+5
Add which features are added or removed in this version. Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20200324051034.30541-1-tao3.xu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26target/i386: reimplement fpatan using floatx80 operationsJoseph Myers2-4/+1554
The x87 fpatan emulation is currently based around conversion to double. This is inherently unsuitable for a good emulation of any floatx80 operation. Reimplement using the soft-float operations, as for other such instructions. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2006230000340.24721@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26target/i386: reimplement fyl2x using floatx80 operationsJoseph Myers2-111/+1423
The x87 fyl2x emulation is currently based around conversion to double. This is inherently unsuitable for a good emulation of any floatx80 operation. Reimplement using the soft-float operations, building on top of the reimplementation of fyl2xp1 and factoring out code to be shared between the two instructions. The included test assumes that the result in round-to-nearest mode should always be one of the two closest floating-point numbers to the mathematically exact result (including that it should be exact, in the exact cases which cover more cases than for fyl2xp1). Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2006172321530.20587@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26target/i386: reimplement fyl2xp1 using floatx80 operationsJoseph Myers2-9/+1358
The x87 fyl2xp1 emulation is currently based around conversion to double. This is inherently unsuitable for a good emulation of any floatx80 operation, even before considering that it is a particularly naive implementation using double (adding 1 then using log rather than attempting a better emulation using log1p). Reimplement using the soft-float operations, as was done for f2xm1; as in that case, m68k has related operations but not exactly this one and it seemed safest to implement directly rather than reusing the m68k code to avoid accumulation of errors. A test is included with many randomly generated inputs. The assumption of the test is that the result in round-to-nearest mode should always be one of the two closest floating-point numbers to the mathematical value of y * log2(x + 1); the implementation aims to do somewhat better than that (about 70 correct bits before rounding). I haven't investigated how accurate hardware is. Intel manuals describe a narrower range of valid arguments to this instruction than AMD manuals. The implementation accepts the wider range (it's needed anyway for the core code to be reusable in a subsequent patch reimplementing fyl2x), but the test only has inputs in the narrower range so that it's valid on hardware that may reject or produce poor results for inputs outside that range. Code in the previous implementation that sets C2 for some out-of-range arguments is not carried forward to the new implementation; C2 is undefined for this instruction and I suspect that code was just cut-and-pasted from the trigonometric instructions (fcos, fptan, fsin, fsincos) where C2 *is* defined to be set for out-of-range arguments. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2006172320190.20587@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26target/i386: reimplement fprem, fprem1 using floatx80 operationsJoseph Myers1-108/+48
The x87 fprem and fprem1 emulation is currently based around conversion to double, which is inherently unsuitable for a good emulation of any floatx80 operation. Reimplement using the soft-float floatx80 remainder operations. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <alpine.DEB.2.21.2006081657200.23637@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26softfloat: return low bits of quotient from floatx80_modremJoseph Myers2-6/+20
Both x87 and m68k need the low parts of the quotient for their remainder operations. Arrange for floatx80_modrem to track those bits and return them via a pointer. The architectures using float32_rem and float64_rem do not appear to need this information, so the *_rem interface is left unchanged and the information returned only from floatx80_modrem. The logic used to determine the low 7 bits of the quotient for m68k (target/m68k/fpu_helper.c:make_quotient) appears completely bogus (it looks at the result of converting the remainder to integer, the quotient having been discarded by that point); this patch does not change that, but the m68k maintainers may wish to do so. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <alpine.DEB.2.21.2006081656500.23637@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26softfloat: do not set denominator high bit for floatx80 remainderJoseph Myers1-1/+0
The floatx80 remainder implementation unnecessarily sets the high bit of bSig explicitly. By that point in the function, arguments that are invalid, zero, infinity or NaN have already been handled and subnormals have been through normalizeFloatx80Subnormal, so the high bit will already be set. Remove the unnecessary code. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <alpine.DEB.2.21.2006081656220.23637@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26softfloat: do not return pseudo-denormal from floatx80 remainderJoseph Myers1-3/+19
The floatx80 remainder implementation sometimes returns the numerator unchanged when the denominator is sufficiently larger than the numerator. But if the value to be returned unchanged is a pseudo-denormal, that is incorrect. Fix it to normalize the numerator in that case. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <alpine.DEB.2.21.2006081655520.23637@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26softfloat: fix floatx80 remainder pseudo-denormal check for zeroJoseph Myers1-1/+1
The floatx80 remainder implementation ignores the high bit of the significand when checking whether an operand (numerator) with zero exponent is zero. This means it mishandles a pseudo-denormal representation of 0x1p-16382L by treating it as zero. Fix this by checking the whole significand instead. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <alpine.DEB.2.21.2006081655180.23637@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26softfloat: merge floatx80_mod and floatx80_remJoseph Myers4-95/+40
The m68k-specific softfloat code includes a function floatx80_mod that is extremely similar to floatx80_rem, but computing the remainder based on truncating the quotient toward zero rather than rounding it to nearest integer. This is also useful for emulating the x87 fprem and fprem1 instructions. Change the floatx80_rem implementation into floatx80_modrem that can perform either operation, with both floatx80_rem and floatx80_mod as thin wrappers available for all targets. There does not appear to be any use for the _mod operation for other floating-point formats in QEMU (the only other architectures using _rem at all are linux-user/arm/nwfpe, for FPA emulation, and openrisc, for instructions that have been removed in the latest version of the architecture), so no change is made to the code for other formats. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <alpine.DEB.2.21.2006081654280.23637@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26target/i386: reimplement f2xm1 using floatx80 operationsJoseph Myers2-3/+1522
The x87 f2xm1 emulation is currently based around conversion to double. This is inherently unsuitable for a good emulation of any floatx80 operation, even before considering that it is a particularly naive implementation using double (computing with pow and then subtracting 1 rather than attempting a better emulation using expm1). Reimplement using the soft-float operations, including additions and multiplications with higher precision where appropriate to limit accumulation of errors. I considered reusing some of the m68k code for transcendental operations, but the instructions don't generally correspond exactly to x87 operations (for example, m68k has 2^x and e^x - 1, but not 2^x - 1); to avoid possible accumulation of errors from applying multiple such operations each rounding to floatx80 precision, I wrote a direct implementation of 2^x - 1 instead. It would be possible in principle to make the implementation more efficient by doing the intermediate operations directly with significands, signs and exponents and not packing / unpacking floatx80 format for each operation, but that would make it significantly more complicated and it's not clear that's worthwhile; the m68k emulation doesn't try to do that. A test is included with many randomly generated inputs. The assumption of the test is that the result in round-to-nearest mode should always be one of the two closest floating-point numbers to the mathematical value of 2^x - 1; the implementation aims to do somewhat better than that (about 70 correct bits before rounding). I haven't investigated how accurate hardware is. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Message-Id: <alpine.DEB.2.21.2006112341010.18393@digraph.polyomino.org.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26xen: Actually fix build without passthroughAnthony PERARD1-1/+1
Fix typo. Fixes: acd0c9416d48 ("xen: fix build without pci passthrough") Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200619103115.254127-1-anthony.perard@citrix.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26Makefile: Install qemu-[qmp/ga]-ref.* into the directory "interop"Liao Pingfang2-6/+8
We need install qemu-[qmp/ga]-ref.* files into the subdirectory of qemu docs: interop. If we visit the following address and click the link to qemu-qmp-ref.html: https://www.qemu.org/docs/master/interop/bitmaps.html#basic-qmp-usage It will report following error: " Not Found The requested URL /docs/master/interop/qemu-qmp-ref.html was not found on this server. " Signed-off-by: Liao Pingfang <liao.pingfang@zte.com.cn> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <1591663670-47712-1-git-send-email-wang.yi59@zte.com.cn> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26hw/scsi/megasas: Fix possible out-of-bounds array access in tracepointsThomas Huth1-13/+23
Some tracepoints in megasas.c use a guest-controlled value as an index into the mfi_frame_desc[] array. Thus a malicious guest could cause an out-of-bounds error here. Fortunately, the impact is very low since this can only happen when the corresponding tracepoints have been enabled before, but the problem should be fixed anyway with a proper check. Buglink: https://bugs.launchpad.net/qemu/+bug/1882065 Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20200615072629.32321-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26docs/nvdimm: add description of alignment requirement of device daxJingqi Liu2-1/+11
For device dax (e.g., /dev/dax0.0), the NUM of 'align=NUM' option needs to match the alignment requirement of the device dax. It must be larger than or equal to the 'align' of device dax. Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Jingqi Liu <jingqi.liu@intel.com> Message-Id: <20200429085011.63752-3-jingqi.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26exec: fetch the alignment of Linux devdax pmem character device nodesJingqi Liu1-1/+53
If the backend file is devdax pmem character device, the alignment specified by the option 'align=NUM' in the '-object memory-backend-file' needs to match the alignment requirement of the devdax pmem character device. This patch uses the interfaces of libdaxctl to fetch the devdax pmem file 'align', so that we can compare it with the NUM of 'align=NUM'. The NUM needs to be larger than or equal to the devdax pmem file 'align'. It also fixes the problem that mmap() returns failure in qemu_ram_mmap() when the NUM of 'align=NUM' is less than the devdax pmem file 'align'. Suggested-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Jingqi Liu <jingqi.liu@intel.com> Message-Id: <20200429085011.63752-2-jingqi.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26configure: add libdaxctl supportJingqi Liu1-0/+29
Add a pair of configure options --{enable,disable}-libdaxctl to control whether QEMU is compiled with libdaxctl [1]. Libdaxctl is a utility library for managing the device dax subsystem. QEMU uses mmap(2) to maps vNVDIMM backends and aligns the mapping address to the page size (getpagesize(2)) by default. However, some types of backends may require an alignment different than the page size. The 'align' option is provided to memory-backend-file to allow users to specify the proper alignment. For device dax (e.g., /dev/dax0.0), the 'align' option needs to match the alignment requirement of the device dax, which can be fetched through the APIs of libdaxctl version 57 or up. [1] Libdaxctl is a part of ndctl project. The project's repository is: https://github.com/pmem/ndctl For more information about libdaxctl APIs, you can refer to the comments in source code of: pmem/ndctl/daxctl/lib/libdaxctl.c. Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Jingqi Liu <jingqi.liu@intel.com> Message-Id: <20200429085011.63752-4-jingqi.liu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26replay: synchronize on every virtual timer callbackPavel Dovgalyuk2-24/+10
Sometimes virtual timer callbacks depend on order of virtual timer processing and warping of virtual clock. Therefore every callback should be logged to make replay deterministic. This patch creates a checkpoint before every virtual timer callback. With these checkpoints virtual timers processing and clock warping events order is completely deterministic. Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> Acked-by: Alex Bennée <alex.bennee@linaro.org> -- v2: - remove mutex lock/unlock for virtual clock checkpoint since it is not process any asynchronous events (commit ca9759c2a92f528f256fef0e3922416f7bb47bf9) - bump record/replay log file version Message-Id: <159012932716.27256.8854065545365559921.stgit@pasha-ThinkPad-X280> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26replay: notify the main loop when there are no instructionsPavel Dovgalyuk1-3/+12
When QEMU is executed in console mode without any external event sources, main loop may sleep for a very long time. But in case of replay there is another event source - event log. This patch adds main loop notification when the vCPU loop has nothing to do and main loop should process the inputs from the event log. Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> Message-Id: <159013007895.28110.2020104406699709721.stgit@pasha-ThinkPad-X280> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26memory: Revert "memory: accept mismatching sizes in memory_region_access_valid"Michael S. Tsirkin1-20/+9
Memory API documentation documents valid .min_access_size and .max_access_size fields and explains that any access outside these boundaries is blocked. This is what devices seem to assume. However this is not what the implementation does: it simply ignores the boundaries unless there's an "accepts" callback. Naturally, this breaks a bunch of devices. Revert to the documented behaviour. Devices that want to allow any access can just drop the valid field, or add the impl field to have accesses converted to appropriate length. Cc: qemu-stable@nongnu.org Reviewed-by: Richard Henderson <rth@twiddle.net> Fixes: CVE-2020-13754 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1842363 Fixes: a014ed07bd5a ("memory: accept mismatching sizes in memory_region_access_valid") Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20200610134731.1514409-1-mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26libqos: pci-pc: use 32-bit write for EJ registerPaolo Bonzini1-1/+1
The memory region ops have min_access_size == 4 so obey it. Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26libqos: usb-hcd-ehci: use 32-bit write for config registerPaolo Bonzini1-1/+1
The memory region ops have min_access_size == 4 so obey it. Tested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26util/getauxval: Porting to FreeBSD getauxval featureDavid CARLIER1-0/+10
From d7f9d40777d1ed7c9450b0be4f957da2993dfc72 Mon Sep 17 00:00:00 2001 From: David Carlier <devnexen@gmail.com> Date: Fri, 12 Jun 2020 09:39:17 +0100 Subject: [PATCH] util/getauxval: Porting to FreeBSD getauxval feature FreeBSD has a similar API for auxiliary vector. Signed-off-by: David Carlier <devnexen@gmail.com> Message-Id: <CA+XhMqxTU6PUSQBpbA9VrS1QZfqgrCAKUCtUF-x2aF=fCMTDOw@mail.gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-26kvm: support to get/set dirty log initial-all-set capabilityJay Zhou1-7/+14
Since the new capability KVM_DIRTY_LOG_INITIALLY_SET of KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 has been introduced in the kernel, tweak the userspace side to detect and enable this capability. Signed-off-by: Jay Zhou <jianjay.zhou@huawei.com> Reviewed-by: Peter Xu <peterx@redhat.com> Message-Id: <20200304025554.2159-1-jianjay.zhou@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-24Rename use_acpi_pci_hotplug to more appropriate use_acpi_hotplug_bridgeAni Sinha1-10/+11
Currently, the option use_acpi_pci_hotplug is being used to control device hotplug capability using ACPI for slots of cold plugged bridges. Hence, we are renaming this option to better reflect what it actually does. Signed-off-by: Ani Sinha <ani.sinha@nutanix.com> Message-Id: <1592310699-58916-1-git-send-email-ani.sinha@nutanix.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Ani Sinha <ani.sinha@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24Stop vhost-user sending uninitialized mmap_offsetsRaphael Norwitz1-6/+6
Prior to this change, the vhost_user_fill_msg_region function filled out all elements of the VhostUserMemoryRegion struct except the mmap_offset. This function is often called on uninitialized structs, which are then copied into VHOST_USER_SET_MEM_TABLE and VHOST_USER_ADD/REM_MEM_REG messages. In some cases, where the mmap_offset was not needed, it was left uninitialized, causing QEMU to send the backend uninitialized data, which Coverity flagged as a series of issues. This change augments the vhost_user_fill_msg_region API, adding a mmap_offset paramenter, forcing the caller to initialize mmap_offset. Fixes: ece99091c2d0aeb23734289a50ef2ff4e0a08929 Fixes: f1aeb14b0809e313c74244d838645ed25e85ea63 Reported-by: Coverity (CIDs 1429802, 1429803 and 1429804) Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com> Message-Id: <1592650156-25845-1-git-send-email-raphael.norwitz@nutanix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-06-24docs/specs/tpm: ACPI boot now supported for TPM/ARMEric Auger1-2/+0
ACPI boot now is supported. Let's remove the comment saying it is not. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200622140620.17229-4-eric.auger@redhat.com> Tested-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24arm/acpi: Add the TPM2.0 device under the DSDTEric Auger1-0/+34
In case it is dynamically instantiated, add the TPM 2.0 device object under the DSDT table in the ACPI namespace. Its HID is MSFT0101 while its current resource settings (CRS) property is initialized with the guest physical address and MMIO size of the device. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200622140620.17229-3-eric.auger@redhat.com> Tested-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24acpi: Some build_tpm2() code reshapeEric Auger2-37/+32
Remove any reference to Acpi20TPM2 and adopt an implementation similar to build_ghes_v2(). Signed-off-by: Eric Auger <eric.auger@redhat.com> Suggested-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200622140620.17229-2-eric.auger@redhat.com> Tested-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24tests/acpi: update expected data filesGerd Hoffmann18-0/+0
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20200619091905.21676-13-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24acpi: q35: drop _SB.PCI0.ISA.LPCD opregion.Gerd Hoffmann1-11/+0
Seems to be unused. ich9 DSDT changes: Scope (_SB.PCI0) { Device (ISA) { Name (_ADR, 0x001F0000) // _ADR: Address OperationRegion (PIRQ, PCI_Config, 0x60, 0x0C) - OperationRegion (LPCD, PCI_Config, 0x80, 0x02) - Field (LPCD, AnyAcc, NoLock, Preserve) - { - COMA, 3, - , 1, - COMB, 3, - Offset (0x01), - LPTD, 2 - } } } Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200619091905.21676-12-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24acpi: drop build_piix4_pm()Gerd Hoffmann1-16/+0
The _SB.PCI0.PX13.P13C opregion (holds isa device enable bits) is not used any more, remove it from DSDT. piix4 DSDT changes: Scope (_SB.PCI0) { - Device (PX13) - { - Name (_ADR, 0x00010003) // _ADR: Address - OperationRegion (P13C, PCI_Config, Zero, 0xFF) - } - } - - Scope (_SB.PCI0) - { Device (ISA) { Name (_ADR, 0x00010000) // _ADR: Address OperationRegion (P40C, PCI_Config, 0x60, 0x04) } } Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Igor Mammedow <imammedo@redhat.com> Message-Id: <20200619091905.21676-11-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24acpi: drop serial/parallel enable bits from dsdtGerd Hoffmann1-23/+0
The _STA methods for COM+LPT used to reference them, but that isn't the case any more. piix4 DSDT changes: Scope (_SB.PCI0) { Device (ISA) { Name (_ADR, 0x00010000) // _ADR: Address OperationRegion (P40C, PCI_Config, 0x60, 0x04) - Field (^PX13.P13C, AnyAcc, NoLock, Preserve) - { - Offset (0x5F), - , 7, - LPEN, 1, - Offset (0x67), - , 3, - CAEN, 1, - , 3, - CBEN, 1 - } } } ich9 DSDT changes: Scope (_SB.PCI0) { Device (ISA) { Name (_ADR, 0x001F0000) // _ADR: Address OperationRegion (PIRQ, PCI_Config, 0x60, 0x0C) OperationRegion (LPCD, PCI_Config, 0x80, 0x02) Field (LPCD, AnyAcc, NoLock, Preserve) { COMA, 3, , 1, COMB, 3, Offset (0x01), LPTD, 2 } - - OperationRegion (LPCE, PCI_Config, 0x82, 0x02) - Field (LPCE, AnyAcc, NoLock, Preserve) - { - CAEN, 1, - CBEN, 1, - LPEN, 1 - } } } Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200619091905.21676-10-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24acpi: simplify build_isa_devices_aml()Gerd Hoffmann1-10/+6
x86 machines can have a single ISA bus only. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200619091905.21676-9-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24acpi: factor out fw_cfg_add_acpi_dsdt()Gerd Hoffmann3-23/+30
Add helper function to add fw_cfg device, also move code to hw/i386/fw_cfg.c. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200619091905.21676-8-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24acpi: move aml builder code for i8042 (kbd+mouse) deviceGerd Hoffmann2-39/+31
DSDT change: isa device order changes in case MI1 (ipmi) is present. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200619091905.21676-7-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24floppy: move cmos_get_fd_drive_type() from pcGerd Hoffmann4-27/+26
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: John Snow <jsnow@redhat.com> Message-Id: <20200619091905.21676-6-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24floppy: make isa_fdc_get_drive_max_chs staticGerd Hoffmann2-4/+2
acpi aml generator needs this, but it is in floppy code now so we can make the function static. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: John Snow <jsnow@redhat.com> Message-Id: <20200619091905.21676-5-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24acpi: move aml builder code for floppy deviceGerd Hoffmann4-83/+91
DSDT change: isa device order changes in case MI1 (ipmi) is present. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200619091905.21676-4-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24acpi: bios-tables-test: show more context on asl diffsGerd Hoffmann1-1/+1
Makes it easier to create good commit messages from the logs. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200619091905.21676-3-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24qtest: allow DSDT acpi table changesGerd Hoffmann1-0/+18
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20200619091905.21676-2-kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-06-24trace/simple: Fix unauthorized enableMarkus Armbruster2-7/+15
st_set_trace_file() accidentally enables tracing. It's called unconditionally during startup, which is why QEMU built with the simple trace backend always writes a trace file "trace-$PID". This has been broken for quite a while. I didn't track down the exact commit. Fix st_set_trace_file() to restore the state. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200527065613.25322-1-armbru@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-06-24scripts/tracetool: Update maintainer email addressPhilippe Mathieu-Daudé18-18/+18
There is an effort in progress to generate a QEMU Python package. As I'm not sure this old email is still valid, update it to not produce package with broken maintainer email. Patch created mechanically by running: $ sed -i 's,\(__email__ *= "\)stefanha@linux.vnet.ibm.com",\1stefanha@redhat.com",' \ $(git grep -l 'email.*stefanha@linux.vnet.ibm.com') Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20200511082816.696-1-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-06-23sd/milkymist-memcard: Fix error API violationMarkus Armbruster1-1/+1
The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. milkymist_memcard_realize() is wrong that way: it passes &err to qdev_prop_set_drive_err() and qdev_realize_and_unref(). Currently harmless, because the latter uses it only as first argument of error_propagate(). Making qdev_prop_set_drive_err() fail involves abuse of -global. Leave handling that to qdev_prop_set_drive(), like we do elsewhere. Cc: Michael Walle <michael@walle.cc> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200622094227.1271650-17-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2020-06-23sd/pxa2xx_mmci: Don't crash on pxa2xx_mmci_init() errorMarkus Armbruster1-12/+3
On error, pxa2xx_mmci_init() reports to stderr and returns NULL. Callers don't check for errors. Machines akita, borzoi, mainstone, spitz, terrier, tosa, and z2 crash shortly after, like this: $ qemu-system-aarch64 -M akita -drive if=sd,readonly=on qemu-system-aarch64: failed to init SD card: Cannot use read-only drive as SD card Segmentation fault (core dumped) Machines connex and verdex reach the check for orphaned drives first: $ aarch64-softmmu/qemu-system-aarch64 -M connex -drive if=sd,readonly=on -accel qtest qemu-system-aarch64: failed to init SD card: Cannot use read-only drive as SD card qemu-system-aarch64: -drive if=sd,readonly=on: machine type does not support if=sd,bus=0,unit=0 Make pxa2xx_mmci_init() fail cleanly right away. Cc: Andrzej Zaborowski <balrogg@gmail.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-arm@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200622094227.1271650-16-armbru@redhat.com>
2020-06-23arm/aspeed: Drop aspeed_board_init_flashes() parameter @errpMarkus Armbruster1-6/+6
We always pass &error_abort. Drop the parameter, use &error_abort directly. Cc: Cédric Le Goater <clg@kaod.org> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Andrew Jeffery <andrew@aj.id.au> Cc: Joel Stanley <joel@jms.id.au> Cc: qemu-arm@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200622094227.1271650-15-armbru@redhat.com>
2020-06-23qdev: Make qdev_prop_set_drive() match the other helpersMarkus Armbruster32-59/+74
qdev_prop_set_drive() can fail. None of the other qdev_prop_set_FOO() can; they abort on error. To clean up this inconsistency, rename qdev_prop_set_drive() to qdev_prop_set_drive_err(), and create a qdev_prop_set_drive() that aborts on error. Coccinelle script to update callers: @ depends on !(file in "hw/core/qdev-properties-system.c")@ expression dev, name, value; symbol error_abort; @@ - qdev_prop_set_drive(dev, name, value, &error_abort); + qdev_prop_set_drive(dev, name, value); @@ expression dev, name, value, errp; @@ - qdev_prop_set_drive(dev, name, value, errp); + qdev_prop_set_drive_err(dev, name, value, errp); Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200622094227.1271650-14-armbru@redhat.com>
2020-06-23qdev: Reject chardev property overrideMarkus Armbruster1-0/+8
qdev_prop_set_chr() screws up when the property already has a non-null value: it neglects to release the old value. Both the old and the new backend become attached to the same device. Unlike for block devices (see previous commit), this can't be observed from the monitor (I think). Example: -serial null -chardev null,id=chr0 -global isa-serial.chardev=chr0 Special case: attempting to use the same backend both times crashes: $ qemu-system-x86_64 --nodefaults -serial null -global isa-serial.chardev=serial0 Unexpected error in qemu_chr_fe_init() at /work/armbru/qemu/chardev/char-fe.c:220: qemu-system-x86_64: Device 'serial0' is in use Aborted (core dumped) Yet another example: -device with multiple chardev=... (but not device_add, which silently drops all but the last duplicate property). Perhaps chardev property override could be made to work. Perhaps it should. I can't afford the time to figure this out now. What I can do reject usage that leaves backends in unhealthy states. For what it's worth, we've long done the same for netdev properties. Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200622094227.1271650-13-armbru@redhat.com>
2020-06-23qdev: Reject drive property overrideMarkus Armbruster2-85/+11
qdev_prop_set_drive() screws up when the property already has a non-null value: it neglects to release the old value. Both the old and the new backend become attached to the same device. Example (taken from iotest 172): -fda ... -drive if=none,... -global floppy.drive=none0. Special case: attempting to use the same backend both times fails. Example (also from iotest 172): -fda ... -global floppy.drive=floppy0. Yet another example: -device with multiple drive=... (but not device_add, which silently drops all but the last duplicate property). Perhaps drive property override could be made to work. Perhaps it should. I can't afford the time to figure this out now. What I can do is reject usage that leaves backends in unhealthy states. For what it's worth, we've long done the same for netdev properties. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200622094227.1271650-12-armbru@redhat.com>