summary refs log tree commit diff stats
path: root/scripts/qapi/source.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2020-10-03disas: Enable capstone disassembly for s390xRichard Henderson3-0/+18
Enable s390x, aka SYSZ, in the git submodule build. Set the capstone parameters for both s390x host and guest. Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-10-03disas: Split out capstone code to disas/capstone.cRichard Henderson5-275/+300
There is nothing target-specific about this code, so it can be added to common_ss. This also requires that the base capstone dependency be added to common_ss, so that we get the correct include paths added to CFLAGS. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-10-03disas: Configure capstone for aarch64 host without libvixlRichard Henderson1-2/+4
The ifdef tangle failed to set cap_arch if libvixl itself was not configured (e.g. due to lack of c++ compiler). Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-10-03disas: Cleanup plugin_disasRichard Henderson1-36/+19
Do not retain a GString in thread-local storage. Allocate a new one and free it on every invocation. Do not g_strdup the result; return the buffer from the GString. Do not use warn_report. Using cs_disasm allocated memory via the &insn parameter, but that was never freed. Use cs_disasm_iter so that we use the memory that we've already allocated, and so that we only try to disassemble one insn, as desired. Do not allocate 1k to hold the bytes for a single instruction. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-10-03disas: Use qemu/bswap.h for bfd endian loadsRichard Henderson2-60/+27
Use the routines we have already instead of open-coding. Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-10-03disas: Clean up CPUDebug initializationRichard Henderson2-241/+151
Rename several functions, dropping "generic" and making "host" vs "target" clearer. Make a bunch of functions static that are not used outside this file. Replace INIT_DISASSEMBLE_INFO with a trio of functions. Acked-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-10-03disas: Move host asm annotations to tb_gen_codeRichard Henderson5-34/+29
Instead of creating GStrings and passing them into log_disas, just print the annotations directly in tb_gen_code. Fix the annotations for the slow paths of the TB, after the part implementing the final guest instruction. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-10-03capstone: Require version 4.0 from a system libraryRichard Henderson1-2/+2
We're about to use a portion of the 4.0 API. Reject a system library version prior to that. Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-10-03capstone: Update to upstream "next" branchRichard Henderson2-1/+2
This branch contains a number of improvements over master, including making all of the disassembler data constant. We are skipping past the 4.0 branchpoint, which changed the location of the includes within the source directory. Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-10-03capstone: Convert Makefile bits to meson bitsRichard Henderson4-80/+120
There are better ways to do this, e.g. meson cmake subproject, but that requires cmake 3.7 and some of our CI environments only provide cmake 3.5. Nor can we add a meson.build file to capstone/, because the git submodule would then always report "untracked files". Fixing that would require creating our own branch on the qemu git mirror, at which point we could just as easily create a native meson subproject. Instead, build the library via the main meson.build. This improves the current state of affairs in that we will re-link the qemu executables against a changed libcapstone.a, which we wouldn't do before-hand. In addition, the use of the configuration header file instead of command-line -DEFINES means that we will rebuild the capstone objects with changes to meson.build. Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-10-02s390x/tcg: Implement CIPHER MESSAGE WITH AUTHENTICATION (KMA)David Hildenbrand3-0/+9
As with the other crypto functions, we only implement subcode 0 (query) and no actual encryption/decryption. We now implement S390_FEAT_MSA_EXT_8. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200928122717.30586-10-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390x/tcg: We support Miscellaneous-Instruction-Extensions Facility 2David Hildenbrand1-0/+1
We implement all relevant instructions. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200928122717.30586-9-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390x/tcg: Implement MULTIPLY SINGLE (MSC, MSGC, MSGRKC, MSRKC)David Hildenbrand5-0/+59
We need new CC handling, determining the CC based on the intermediate result (64bit for MSC and MSRKC, 128bit for MSGC and MSGRKC). We want to store out2 ("low") after muls128 to r1, so add "wout_out2_r1". Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200928122717.30586-8-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390x/tcg: Implement BRANCH INDIRECT ON CONDITION (BIC)David Hildenbrand2-0/+10
Just like BRANCH ON CONDITION - however the address is read from memory (always 8 bytes are read), we have to wrap the address manually. The address is read using current CPU DAT/address-space controls, just like ordinary data. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200928122717.30586-7-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390x/tcg: Implement MULTIPLY HALFWORD (MGH)David Hildenbrand1-0/+1
Just like MULTIPLY HALFWORD IMMEDIATE (MGHI), only the second operand (signed 16 bit) comes from memory. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200928122717.30586-6-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390x/tcg: Implement MULTIPLY (MG, MGRK)David Hildenbrand2-0/+15
Multiply two signed 64bit values and store the 128bit result in r1 (0-63) and r1 + 1 (64-127). Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200928122717.30586-5-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390x/tcg: Implement SUBTRACT HALFWORD (SGH)David Hildenbrand1-0/+1
Easy to wire up. Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200928122717.30586-4-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390x/tcg: Implement ADD HALFWORD (AGH)David Hildenbrand2-0/+2
Easy, just like ADD HALFWORD IMMEDIATE (AGHI). Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200928122717.30586-3-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390x/cpumodel: S390_FEAT_MISC_INSTRUCTION_EXT -> ↵David Hildenbrand2-2/+2
S390_FEAT_MISC_INSTRUCTION_EXT2 Let's avoid confusion with the "Miscellaneous-Instruction-Extensions Facility 1" Suggested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20200928122717.30586-2-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02vfio-ccw: plug memory leak while getting region infoCornelia Huck1-1/+4
vfio_get_dev_region_info() unconditionally allocates memory for a passed-in vfio_region_info structure (and does not re-use an already allocated structure). Therefore, we have to free the structure we pass to that function in vfio_ccw_get_region() for every region we successfully obtained information for. Fixes: 8fadea24de4e ("vfio-ccw: support async command subregion") Fixes: 46ea3841edaf ("vfio-ccw: Add support for the schib region") Fixes: f030532f2ad6 ("vfio-ccw: Add support for the CRW region and IRQ") Reported-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200928101701.13540-1-cohuck@redhat.com>
2020-10-02s390x/tcg: Implement MONITOR CALLDavid Hildenbrand4-0/+48
Recent upstream Linux uses the MONITOR CALL instruction for things like BUG_ON() and WARN_ON(). We currently inject an operation exception when we hit a MONITOR CALL instruction - which is wrong, as the instruction is not glued to specific CPU features. Doing a simple WARN_ON_ONCE() currently results in a panic: [ 18.162801] illegal operation: 0001 ilc:2 [#1] SMP [ 18.162889] Modules linked in: [...] [ 18.165476] Kernel panic - not syncing: Fatal exception: panic_on_oops With a proper implementation, we now get: [ 18.242754] ------------[ cut here ]------------ [ 18.242855] WARNING: CPU: 7 PID: 1 at init/main.c:1534 [...] [ 18.242919] Modules linked in: [...] [ 18.246262] ---[ end trace a420477d71dc97b4 ]--- [ 18.259014] Freeing unused kernel memory: 4220K Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200918085122.26132-1-david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390: guest support for diagnose 0x318Collin Walling9-0/+77
DIAGNOSE 0x318 (diag318) is an s390 instruction that allows the storage of diagnostic information that is collected by the firmware in the case of hardware/firmware service events. QEMU handles the instruction by storing the info in the CPU state. A subsequent register sync will communicate the data to the hypervisor. QEMU handles the migration via a VM State Description. This feature depends on the Extended-Length SCCB (els) feature. If els is not present, then a warning will be printed and the SCLP bit that allows the Linux kernel to execute the instruction will not be set. Availability of this instruction is determined by byte 134 (aka fac134) bit 0 of the SCLP Read Info block. This coincidentally expands into the space used for CPU entries, which means VMs running with the diag318 capability may not be able to read information regarding all CPUs unless the guest kernel supports an extended-length SCCB. This feature is not supported in protected virtualization mode. Signed-off-by: Collin Walling <walling@linux.ibm.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Acked-by: Thomas Huth <thuth@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Acked-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-Id: <20200915194416.107460-9-walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390/sclp: add extended-length sccb support for kvm guestCollin Walling5-6/+48
As more features and facilities are added to the Read SCP Info (RSCPI) response, more space is required to store them. The space used to store these new features intrudes on the space originally used to store CPU entries. This means as more features and facilities are added to the RSCPI response, less space can be used to store CPU entries. With the Extended-Length SCCB (ELS) facility, a KVM guest can execute the RSCPI command and determine if the SCCB is large enough to store a complete reponse. If it is not large enough, then the required length will be set in the SCCB header. The caller of the SCLP command is responsible for creating a large-enough SCCB to store a complete response. Proper checking should be in place, and the caller should execute the command once-more with the large-enough SCCB. This facility also enables an extended SCCB for the Read CPU Info (RCPUI) command. When this facility is enabled, the boundary violation response cannot be a result from the RSCPI, RSCPI Forced, or RCPUI commands. In order to tolerate kernels that do not yet have full support for this feature, a "fixed" offset to the start of the CPU Entries within the Read SCP Info struct is set to allow for the original 248 max entries when this feature is disabled. Additionally, this is introduced as a CPU feature to protect the guest from migrating to a machine that does not support storing an extended SCCB. This could otherwise hinder the VM from being able to read all available CPU entries after migration (such as during re-ipl). Signed-off-by: Collin Walling <walling@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-Id: <20200915194416.107460-7-walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390/sclp: use cpu offset to locate cpu entriesCollin Walling1-2/+4
The start of the CPU entry region in the Read SCP Info response data is denoted by the offset_cpu field. As such, QEMU needs to begin creating entries at this address. This is in preparation for when Read SCP Info inevitably introduces new bytes that push the start of the CPUEntry field further away. Read CPU Info is unlikely to ever change, so let's not bother accounting for the offset there. Signed-off-by: Collin Walling <walling@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-Id: <20200915194416.107460-6-walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390/sclp: check sccb len before filling in dataCollin Walling1-12/+14
The SCCB must be checked for a sufficient length before it is filled with any data. If the length is insufficient, then the SCLP command is suppressed and the proper response code is set in the SCCB header. While we're at it, let's cleanup the length check by placing the calculation inside a macro. Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length") Signed-off-by: Collin Walling <walling@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-Id: <20200915194416.107460-5-walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390/sclp: read sccb from mem based on provided lengthCollin Walling3-26/+33
The header contained within the SCCB passed to the SCLP service call contains the actual length of the SCCB. Instead of allocating a static 4K size for the work sccb, let's allow for a variable size determined by the value in the header. The proper checks are already in place to ensure the SCCB length is sufficent to store a full response and that the length does not cross any explicitly-set boundaries. Signed-off-by: Collin Walling <walling@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-Id: <20200915194416.107460-4-walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390/sclp: rework sclp boundary checksCollin Walling1-1/+18
Rework the SCLP boundary check to account for different SCLP commands (eventually) allowing different boundary sizes. Signed-off-by: Collin Walling <walling@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-Id: <20200915194416.107460-3-walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02s390/sclp: get machine once during read scp/cpu infoCollin Walling1-4/+4
Functions within read scp/cpu info will need access to the machine state. Let's make a call to retrieve the machine state once and pass the appropriate data to the respective functions. Signed-off-by: Collin Walling <walling@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-Id: <20200915194416.107460-2-walling@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02hw/s390x/css: Remove double initializationPhilippe Mathieu-Daudé1-1/+0
Fix eventual copy/paste mistake introduced in commit bc994b74ea ("s390x/css: Use static initialization for channel_subsys fields"). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20200907024020.854465-1-philmd@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-10-02gitlab: split deprecated job into build/check stagesAlex Bennée1-1/+16
While the job is pretty fast for only a few targets we still want to catch breakage of the build. By splitting the test step we can allow_failures for that while still ensuring we don't miss the build breaking. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201002091538.3017-1-alex.bennee@linaro.org>
2020-10-02gitlab: move linux-user plugins test across to gitlabAlex Bennée2-11/+11
Even with the recent split moving beefier plugins into contrib and dropping them from the check-tcg tests we are still hitting time limits. This possibly points to a slow down of --debug-tcg but seeing as we are migrating stuff to gitlab we might as well move there and bump the timeout. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201002103223.24022-1-alex.bennee@linaro.org>
2020-10-02configure: Bump the minimum required Python version to 3.6Thomas Huth3-6/+4
All our supported build platforms have Python 3.6 or newer nowadays, and there are some useful features in Python 3.6 which are not available in 3.5 yet (e.g. the type hint annotations which will allow us to statically type the QAPI parser), so let's bump the minimum Python version to 3.6 now. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200923162908.95372-1-thuth@redhat.com> Message-Id: <20200925154027.12672-16-alex.bennee@linaro.org>
2020-10-02gitlab-ci: Increase the timeout for the cross-compiler buildsThomas Huth1-0/+1
Some of the cross-compiler builds (the mips build and the win64 build for example) are quite slow and sometimes hit the 1h time limit. Increase the limit a little bit to make sure that we do not get failures in the CI runs just because of some few minutes. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200921174320.46062-7-thuth@redhat.com> Message-Id: <20200925154027.12672-15-alex.bennee@linaro.org>
2020-10-02tests/docker: Remove old Debian 9 containersThomas Huth5-148/+0
We do not support Debian 9 in QEMU anymore, and the Debian 9 containers are now no longer used in the gitlab-CI. Time to remove them. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200921174320.46062-6-thuth@redhat.com> Message-Id: <20200925154027.12672-14-alex.bennee@linaro.org>
2020-10-02shippable.yml: Remove the Debian9-based MinGW cross-compiler testsThomas Huth1-4/+0
We're not supporting Debian 9 anymore, and we are now testing MinGW cross-compiler builds in the gitlab-CI, too, so we do not really need these jobs in the shippable.yml anymore. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200921174320.46062-5-thuth@redhat.com> Message-Id: <20200925154027.12672-13-alex.bennee@linaro.org>
2020-10-02tests/docker: Update the tricore container to debian 10Thomas Huth3-3/+3
We do not support Debian 9 anymore, thus update the Tricore container to Debian 10 now. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200921174320.46062-4-thuth@redhat.com> Message-Id: <20200925154027.12672-12-alex.bennee@linaro.org>
2020-10-02gitlab-ci: Remove the Debian9-based containers and containers-layer3Thomas Huth2-15/+0
According to our support policy, Debian 9 is not supported by the QEMU project anymore. Since we now switched the MinGW cross-compiler builds to Fedora, we do not need these Debian9-based containers in the gitlab-CI anymore, and can now also get rid of the "layer3" container build stage this way. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200921174320.46062-3-thuth@redhat.com> Message-Id: <20200925154027.12672-11-alex.bennee@linaro.org>
2020-10-02tests/docker: Use Fedora containers for MinGW cross-builds in the gitlab-CIThomas Huth4-2/+92
According to our support policy, we do not support Debian 9 in QEMU anymore, and we only support building the Windows binaries with a very recent version of the MinGW toolchain. So we should not test the MinGW cross-compilation with Debian 9 anymore, but switch to something newer like Fedora. To do this, we need a separate Fedora container for each build that provides the QEMU_CONFIGURE_OPTS environment variable. Unfortunately, the MinGW 64-bit compiler seems to be a little bit slow, so we also have to disable some features like "capstone" in the build here to make sure that the CI pipelines still finish within a reasonable amount of time. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200921174320.46062-2-thuth@redhat.com> Message-Id: <20200925154027.12672-10-alex.bennee@linaro.org>
2020-10-02travis.yml: Drop the Python 3.5 buildThomas Huth1-9/+0
We are soon going to remove the support for Python 3.5. So remove the CI job now. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200922070441.48844-1-thuth@redhat.com> Message-Id: <20200925154027.12672-9-alex.bennee@linaro.org>
2020-10-02travis.yml: Drop the superfluous Python 3.6 buildThomas Huth1-8/+0
Python 3.6 is already the default Python in the jobs that are based on Ubuntu Bionic, so it does not make much sense to test this again separately. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200918103430.297167-7-thuth@redhat.com> Message-Id: <20200925154027.12672-8-alex.bennee@linaro.org>
2020-10-02travis.yml: Update Travis to use Bionic and Focal instead of XenialThomas Huth1-11/+13
According to our support policy, we do not support Xenial anymore. Time to switch the bigger parts of the builds to Focal instead. Some few jobs have to be updated to Bionic instead, since they are currently still failing on Focal otherwise. Also "--disable-pie" is causing linker problems with newer versions of Ubuntu ... so remove that switch from the jobs now (we still test it in a gitlab CI job, so we don't lose much test coverage here). Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Cleber Rosa <crosa@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-Id: <20200918103430.297167-6-thuth@redhat.com> Message-Id: <20200925154027.12672-7-alex.bennee@linaro.org>
2020-10-02travis.yml: Drop the default softmmu buildsThomas Huth1-14/+0
The total runtime of all Travis jobs is very long and we are testing all softmmu targets in the gitlab-CI already - so we can speed up the Travis testing a little bit by not testing the softmmu targets here anymore. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Acked-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200918103430.297167-5-thuth@redhat.com> Message-Id: <20200925154027.12672-6-alex.bennee@linaro.org>
2020-10-02migration: Silence compiler warning in global_state_store_running()Thomas Huth1-2/+2
GCC 9.3.0 on Ubuntu complains: In file included from /usr/include/string.h:495, from /home/travis/build/huth/qemu/include/qemu/osdep.h:87, from ../migration/global_state.c:13: In function ‘strncpy’, inlined from ‘global_state_store_running’ at ../migration/global_state.c:47:5: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound 100 equals destination size [-Werror=stringop-truncation] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... but we apparently really want to do a strncpy here - the size is already checked with the assert() statement right in front of it. To silence the warning, simply replace it with our strpadcpy() function. Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com> (two years ago) Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200918103430.297167-4-thuth@redhat.com> Message-Id: <20200925154027.12672-5-alex.bennee@linaro.org>
2020-10-01ide: cancel pending callbacks on SRSTJohn Snow1-18/+40
The SRST implementation did not keep up with the rest of IDE; it is possible to perform a weak reset on an IDE device to remove the BSY/DRQ bits, and then issue writes to the control/device registers which can cause chaos with the state machine. Fix that by actually performing a real reset. Reported-by: Alexander Bulekov <alxndr@bu.edu> Fixes: https://bugs.launchpad.net/qemu/+bug/1878253 Fixes: https://bugs.launchpad.net/qemu/+bug/1887303 Fixes: https://bugs.launchpad.net/qemu/+bug/1887309 Signed-off-by: John Snow <jsnow@redhat.com>
2020-10-01ide: clear interrupt on command writeJohn Snow1-0/+1
Not known to fix any bug, but I couldn't help but notice that ATA specifies that writing to this register should clear an interrupt. ATA7: Section 5.3.3 (Command register - Effect) ATA6: Section 7.4.4 (Command register - Effect) ATA5: Section 7.4.4 (Command register - Effect) ATA4: Section 7.4.4 (Command register - Effect) ATA3: Section 5.2.2 (Command register) Other editions: try searching for the phrase "Writing this register". Signed-off-by: John Snow <jsnow@redhat.com>
2020-10-01ide: remove magic constants from the device registerJohn Snow2-12/+25
(In QEMU, we call this the "select" register.) My memory isn't good enough to memorize what these magic runes do. Label them to prevent mixups from happening in the future. Side note: I assume it's safe to always set 0xA0 even though ATA2 claims these bits are reserved, because ATA3 immediately reinstated that these bits should be always on. ATA4 and subsequent specs only claim that the fields are obsolete, so I assume it's safe to leave these set and that it should work with the widest array of guests. Signed-off-by: John Snow <jsnow@redhat.com>
2020-10-01ide: reorder set/get sector functionsJohn Snow1-11/+15
Reorder these just a pinch to make them more obvious at a glance what the addressing mode is. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-10-01ide: model HOB correctlyJohn Snow2-8/+8
I have been staring at this FIXME for years and I never knew what it meant. I finally stumbled across it! When writing to the command registers, the old value is shifted into a HOB copy of the register and the new value is written into the primary register. When reading registers, the value retrieved is dependent on the HOB bit in the CONTROL register. By setting bit 7 (0x80) in CONTROL, any register read will, if it has one, yield the HOB value for that register instead. Our code has a problem: We were using bit 7 of the DEVICE register to model this. We use bus->cmd roughly as the control register already, as it stores the value from ide_ctrl_write. Lastly, all command register writes reset the HOB, so fix that, too. Signed-off-by: John Snow <jsnow@redhat.com>
2020-10-01ide: don't tamper with the device registerJohn Snow1-2/+2
In real ISA operation, register writes go out to an entire bus channel and all listening devices receive the write. The devices do not toggle the DEV bit based on their own configuration, nor does the HBA intermediate or tamper with that value. The reality of the matter is that DEV0/DEV1 accordingly will react to command register writes based on whether or not the device was selected. This does not fix a known bug, but it makes the code slightly simpler and more obvious. Signed-off-by: John Snow <jsnow@redhat.com>
2020-10-01ide: rename cmd_write to ctrl_writeJohn Snow7-23/+24
It's the Control register, part of the Control block -- Command is misleading here. Rename all related functions and constants. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>