aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2020-10-02s390: guest support for diagnose 0x318Collin Walling1-0/+5
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 Walling1-6/+37
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 Walling2-25/+32
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-01Merge remote-tracking branch 'remotes/jsnow-gitlab/tags/ide-pull-request' ↵Peter Maydell7-62/+90
into staging Pull request # gpg: Signature made Thu 01 Oct 2020 18:41:05 BST # gpg: using RSA key F9B7ABDBBCACDF95BE76CBD07DEF8106AAFC390E # gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>" [full] # Primary key fingerprint: FAEB 9711 A12C F475 812F 18F2 88A9 064D 1835 61EB # Subkey fingerprint: F9B7 ABDB BCAC DF95 BE76 CBD0 7DEF 8106 AAFC 390E * remotes/jsnow-gitlab/tags/ide-pull-request: ide: cancel pending callbacks on SRST ide: clear interrupt on command write ide: remove magic constants from the device register ide: reorder set/get sector functions ide: model HOB correctly ide: don't tamper with the device register ide: rename cmd_write to ctrl_write hw/ide/ahci: Do not dma_memory_unmap(NULL) MAINTAINERS: Update my git address Signed-off-by: Peter Maydell <peter.maydell@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 Snow1-12/+14
(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 Snow1-8/+7
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 Snow6-19/+19
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>
2020-10-01hw/ide/ahci: Do not dma_memory_unmap(NULL)Philippe Mathieu-Daudé1-1/+1
libFuzzer triggered the following assertion: cat << EOF | qemu-system-i386 -M pc-q35-5.0 \ -nographic -monitor none -serial none -qtest stdio outl 0xcf8 0x8000fa24 outl 0xcfc 0xe1068000 outl 0xcf8 0x8000fa04 outw 0xcfc 0x7 outl 0xcf8 0x8000fb20 write 0xe1068304 0x1 0x21 write 0xe1068318 0x1 0x21 write 0xe1068384 0x1 0x21 write 0xe1068398 0x2 0x21 EOF qemu-system-i386: exec.c:3621: address_space_unmap: Assertion `mr != NULL' failed. Aborted (core dumped) This is because we don't check the return value from dma_memory_map() which can return NULL, then we call dma_memory_unmap(NULL) which is illegal. Fix by only unmap if the value is not NULL (and the size is not the expected one). Cc: qemu-stable@nongnu.org Reported-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200718072854.7001-1-f4bug@amsat.org Fixes: f6ad2e32f8 ("ahci: add ahci emulation") BugLink: https://bugs.launchpad.net/qemu/+bug/1884693 Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com>
2020-10-01Merge remote-tracking branch ↵Peter Maydell3-73/+128
'remotes/pmaydell/tags/pull-target-arm-20201001' into staging target-arm queue: * Make isar_feature_aa32_fp16_arith() handle M-profile * Fix SVE splice * Fix SVE LDR/STR * Remove ignore_memory_transaction_failures on the raspi2 * raspi: Various cleanup/refactoring # gpg: Signature made Thu 01 Oct 2020 15:46:47 BST # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20201001: hw/arm/raspi: Remove use of the 'version' value in the board code hw/arm/raspi: Use RaspiProcessorId to set the firmware load address hw/arm/raspi: Introduce RaspiProcessorId enum hw/arm/raspi: Use more specific machine names hw/arm/raspi: Avoid using TypeInfo::class_data pointer hw/arm/raspi: Move arm_boot_info structure to RaspiMachineState hw/arm/raspi: Load the firmware on the first core hw/arm/raspi: Display the board revision in the machine description hw/arm/raspi: Remove ignore_memory_transaction_failures on the raspi2 hw/arm/bcm2835: Add more unimplemented peripherals hw/arm/raspi: Define various blocks base addresses target/arm: Fix SVE splice target/arm: Fix sve ldr/str target/arm: Make isar_feature_aa32_fp16_arith() handle M-profile target/arm: Add ID register values for Cortex-M0 hw/intc/armv7m_nvic: Only show ID register values for Main Extension CPUs target/arm: Move id_pfr0, id_pfr1 into ARMISARegisters target/arm: Replace ARM_FEATURE_PXN with ID_MMFR0.VMSA check Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-01hw/arm/raspi: Remove use of the 'version' value in the board codePhilippe Mathieu-Daudé1-16/+13
We expected the 'version' ID to match the board processor ID, but this is not always true (for example boards with revision id 0xa02042/0xa22042 are Raspberry Pi 2 with a BCM2837 SoC). This was not important because we were not modelling them, but since the recent refactor now allow to model these boards, it is safer to check the processor id directly. Remove the version check. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200924111808.77168-9-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-01hw/arm/raspi: Use RaspiProcessorId to set the firmware load addressPhilippe Mathieu-Daudé1-1/+2
The firmware load address depends on the SoC ("processor id") used, not on the version of the board. Suggested-by: Luc Michel <luc.michel@greensocs.com> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200924111808.77168-8-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-01hw/arm/raspi: Introduce RaspiProcessorId enumPhilippe Mathieu-Daudé1-24/+21
As we only support a reduced set of the REV_CODE_PROCESSOR id encoded in the board revision, define the PROCESSOR_ID values as an enum. We can simplify the board_soc_type and cores_count methods. Reviewed-by: Luc Michel <luc.michel@greensocs.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200924111808.77168-7-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-01hw/arm/raspi: Use more specific machine namesPhilippe Mathieu-Daudé1-2/+4
Now that we can instantiate different machines based on their board_rev register value, we can have various raspi2 and raspi3. In commit fc78a990ec103 we corrected the machine description. Correct the machine names too. For backward compatibility, add an alias to the previous generic name. Reviewed-by: Luc Michel <luc.michel@greensocs.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200924111808.77168-6-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-01hw/arm/raspi: Avoid using TypeInfo::class_data pointerPhilippe Mathieu-Daudé1-10/+24
Using class_data pointer to create a MachineClass is not the recommended way anymore. The correct way is to open-code the MachineClass::fields in the class_init() method. We can not use TYPE_RASPI_MACHINE::class_base_init() because it is called *before* each machine class_init(), therefore the board_rev field is not populated. We have to manually call raspi_machine_class_common_init() for each machine. This partly reverts commit a03bde3674e. Suggested-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200924111808.77168-5-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-01hw/arm/raspi: Move arm_boot_info structure to RaspiMachineStatePhilippe Mathieu-Daudé1-15/+15
The arm_boot_info structure belong to the machine, move it to RaspiMachineState. Reviewed-by: Luc Michel <luc.michel@greensocs.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200924111808.77168-4-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-01hw/arm/raspi: Load the firmware on the first corePhilippe Mathieu-Daudé1-1/+2
The 'first_cpu' is more a QEMU accelerator-related concept than a variable the machine requires to use. Since the machine is aware of its CPUs, directly use the first one to load the firmware. Reviewed-by: Luc Michel <luc.michel@greensocs.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200924111808.77168-3-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-01hw/arm/raspi: Display the board revision in the machine descriptionPhilippe Mathieu-Daudé1-1/+3
Display the board revision in the machine description. Before: $ qemu-system-aarch64 -M help | fgrep raspi raspi2 Raspberry Pi 2B raspi3 Raspberry Pi 3B After: raspi2 Raspberry Pi 2B (revision 1.1) raspi3 Raspberry Pi 3B (revision 1.2) Reviewed-by: Luc Michel <luc.michel@greensocs.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200924111808.77168-2-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-01hw/arm/raspi: Remove ignore_memory_transaction_failures on the raspi2Philippe Mathieu-Daudé1-3/+0
Commit 1c3db49d39 added the raspi3, which uses the same peripherals than the raspi2 (but with different ARM cores). The raspi3 was introduced without the ignore_memory_transaction_failures flag. Almost 2 years later, the machine is usable running U-Boot and Linux. In commit 00cbd5bd74 we mapped a lot of unimplemented devices, commit d442d95f added thermal block and commit 0e5bbd7406 the system timer. As we are happy with the raspi3, let's remove this flag on the raspi2. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200921034729.432931-4-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-01hw/arm/bcm2835: Add more unimplemented peripheralsPhilippe Mathieu-Daudé1-0/+2
The bcm2835-v3d is used since Linux 4.7, see commit 49ac67e0c39c ("ARM: bcm2835: Add VC4 to the device tree"), and the bcm2835-txp since Linux 4.19, see commit b7dd29b401f5 ("ARM: dts: bcm283x: Add Transposer block"). Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Message-id: 20200921034729.432931-3-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-01hw/intc/armv7m_nvic: Only show ID register values for Main Extension CPUsPeter Maydell1-0/+42
M-profile CPUs only implement the ID registers as guest-visible if the CPU implements the Main Extension (all our current CPUs except the Cortex-M0 do). Currently we handle this by having the Cortex-M0 leave the ID register values in the ARMCPU struct as zero, but this conflicts with our design decision to make QEMU behaviour be keyed off ID register fields wherever possible. Explicitly code the ID registers in the NVIC to return 0 if the Main Extension is not implemented, so we can make the M0 model set the ARMCPU struct fields to obtain the correct behaviour without those values becoming guest-visible. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200910173855.4068-4-peter.maydell@linaro.org
2020-10-01target/arm: Move id_pfr0, id_pfr1 into ARMISARegistersPeter Maydell1-2/+2
Move the id_pfr0 and id_pfr1 fields into the ARMISARegisters sub-struct. We're going to want id_pfr1 for an isar_features check, and moving both at the same time avoids an odd inconsistency. Changes other than the ones to cpu.h and kvm64.c made automatically with: perl -p -i -e 's/cpu->id_pfr/cpu->isar.id_pfr/' target/arm/*.c hw/intc/armv7m_nvic.c Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200910173855.4068-3-peter.maydell@linaro.org
2020-10-01Merge remote-tracking branch ↵Peter Maydell7-171/+293
'remotes/kraxel/tags/microvm-20200930-pull-request' into staging microvm: add pcie support. # gpg: Signature made Wed 30 Sep 2020 18:48:41 BST # gpg: using RSA key 4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full] # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full] # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full] # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/microvm-20200930-pull-request: tests/acpi: update expected data files acpi/gpex: no reason to use a method for _CRS tests/acpi: add microvm pcie test tests/acpi: factor out common microvm test setup tests/acpi: add empty tests/data/acpi/microvm/DSDT.pcie file tests/acpi: allow updates for expected data files microvm/pcie: add 64bit mmio window microvm: add pcie support microvm: add irq table arm: use acpi_dsdt_add_gpex acpi: add acpi_dsdt_add_gpex move MemMapEntry Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-09-30hw/net/can: Correct Kconfig dependenciesPavel Pisa1-4/+3
The original CAN_PCI config option enables multiple SJA1000 PCI boards emulation build. These boards bridge SJA1000 into I/O or memory address space of the host CPU and depend on SJA1000 emulation. Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Message-Id: <dd332de687bfe52bbec37f5de1d861fb8e620d74.1600069689.git.pisa@cmp.felk.cvut.cz> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/net/can: CTU CAN FD IP open hardware core emulation.Jan Charvat5-0/+1117
The implementation of the model of complete open-source/design/hardware CAN FD controller. The IP core project has been started and is maintained by Ondrej Ille at Czech Technical University in Prague. CTU CAN FD project pages: https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core CAN bus CTU FEE Projects Listing page: http://canbus.pages.fel.cvut.cz/ The core is mapped to PCIe card same as on one of its real hardware adaptations. The device implementing two CTU CAN FD ip cores is instantiated after CAN bus definition -object can-bus,id=canbus0-bus by QEMU parameters -device ctucan_pci,canbus0=canbus0-bus,canbus1=canbus0-bus Signed-off-by: Jan Charvat <charvj10@fel.cvut.cz> Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Message-Id: <23e3ca4dcb2cc9900991016910a6cab7686c0e31.1600069689.git.pisa@cmp.felk.cvut.cz> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/net/can/ctucafd: Add CTU CAN FD core register definitions.Jan Charvat2-0/+1160
Definitions of registers and CAN FD frame message box of CTU CAN FD IP core are generated the specification in CACTUS/IP-XACT format. CTU CAN FD IP core repository https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core The location of the CTU CAN IP core specification within IP core design spec/CTU/ip/CAN_FD_IP_Core/2.1/CAN_FD_IP_Core.2.1.xml The header files are generated by pyXact_generator designed by Ondrej Ille which is based on ipyxact_parser. The specification is source of header files for driver and emulation, documentation and VHDL registers map implementation. Signed-off-by: Jan Charvat <charvj10@fel.cvut.cz> Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Message-Id: <97ae620f724bf1d76f127aaf628f7aec3af0a11c.1600069689.git.pisa@cmp.felk.cvut.cz> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/net/can: sja1000 ignore CAN FD framesJan Charvat1-6/+23
Signed-off-by: Jan Charvat <charvj10@fel.cvut.cz> Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Reviewed-by: Vikram Garhwal <fnu.vikram@xilinx.com> Message-Id: <48d9ebf6b64e7652851c12fe4566e06b44803372.1600069689.git.pisa@cmp.felk.cvut.cz> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30net/can: Initial host SocketCan support for CAN FD.Jan Charvat1-0/+2
Signed-off-by: Jan Charvat <charvj10@fel.cvut.cz> Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Reviewed-by: Vikram Garhwal <fnu.vikram@xilinx.com> Message-Id: <41383d4eb3f35586c696a8e29c4dff4031a81338.1600069689.git.pisa@cmp.felk.cvut.cz> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30target/i386: always create kvmclock deviceVitaly Kuznetsov5-6/+16
QEMU's kvmclock device is only created when KVM PV feature bits for kvmclock (KVM_FEATURE_CLOCKSOURCE/KVM_FEATURE_CLOCKSOURCE2) are exposed to the guest. With 'kvm=off' cpu flag the device is not created and we don't call KVM_GET_CLOCK/KVM_SET_CLOCK upon migration. It was reported that without these call at least Hyper-V TSC page clocksouce (which can be enabled independently) gets broken after migration. Switch to creating kvmclock QEMU device unconditionally, it seems to always make sense to call KVM_GET_CLOCK/KVM_SET_CLOCK on migration. Use KVM_CAP_ADJUST_CLOCK check instead of CPUID feature bits. Reported-by: Antoine Damhet <antoine.damhet@blade-group.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20200922151934.899555-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/xen: Split x86-specific declaration from generic hardware onesPhilippe Mathieu-Daudé2-1/+2
xen_hvm_init() is restricted to the X86 architecture. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200908155530.249806-6-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/i386/xen: Rename X86/PC specific function as xen_hvm_init_pc()Philippe Mathieu-Daudé2-4/+4
xen_hvm_init() is only meanful to initialize a X86/PC machine, rename it as xen_hvm_init_pc(). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200908155530.249806-3-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/i386/q35: Remove unreachable Xen code on Q35 machinePhilippe Mathieu-Daudé1-11/+2
Xen accelerator requires specific changes to a machine to be able to use it. See for example the 'Xen PC' machine configure its PCI bus calling pc_xen_hvm_init_pci(). There is no 'Xen Q35' machine declared. This code was probably added while introducing the Q35 machine, based on the existing PC machine (see commit df2d8b3ed4 "Introduce q35 pc based chipset emulator"). Remove the unreachable code to simplify this file. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200722082517.18708-1-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw: megasas: consider 'iov_count=0' is an error in megasas_map_sglLi Qiang1-1/+1
Currently in 'megasas_map_sgl' when 'iov_count=0' will just return success however the 'cmd' doens't contain any iov. This will cause the assert in 'scsi_dma_complete' failed. This is because in 'dma_blk_cb' the 'dbs->sg_cur_index == dbs->sg->nsg' will be true and just call 'dma_complete'. However now there is no aiocb returned. This fixes the LP#1878263: -->https://bugs.launchpad.net/qemu/+bug/1878263 Reported-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Li Qiang <liq3ea@163.com> Message-Id: <20200815141940.44025-3-liq3ea@163.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw: megasas: return -1 when 'megasas_map_sgl' failsLi Qiang1-2/+2
The caller of 'megasas_map_sgl' will only check if the return is zero or not. If it return 0 it means success, as in the next patch we will consider 'iov_count=0' is an error, so let's return -1 to indicate a failure. Signed-off-by: Li Qiang <liq3ea@163.com> Message-Id: <20200815141940.44025-2-liq3ea@163.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30scsi-generic: Fix HM-zoned device scanDmitry Fomichev1-4/+6
Several important steps during device scan depend on SCSI type of the device. For example, max_transfer property is only determined and assigned if the device has the type of TYPE_DISK. Host-managed ZBC disks retain most of the properties of regular SCSI drives, but they have their own SCSI device type, 0x14. This prevents the proper assignment of max_transfer property for HM-zoned devices in scsi-generic driver leading to I/O errors if the maximum i/o size calculated at the guest exceeds the host value. To fix this, define TYPE_ZBC to have the standard value from SCSI ZBC standard spec. Several scan steps that were previously done only for TYPE_DISK devices, are now performed for the SCSI devices having TYPE_ZBC too. Reported-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Dmitry Fomichev <dmitry.fomichev@wdc.com> Message-Id: <20200811225122.17342-3-dmitry.fomichev@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/char/serial-{isa, pci}: Alias QDEV properties from generic serial objectPhilippe Mathieu-Daudé2-3/+4
Instead of overwritting the properties of the generic 'state' object, alias them. Note we can now propagate the "baudbase" property. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200907015535.827885-7-f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/char/serial: Make 'wakeup' property booleanPhilippe Mathieu-Daudé2-1/+2
Make the "wakeup" property introduced in commit 9826fd597df ("suspend: make serial ports wakeup the guest") a boolean. As we want to reuse the generic serial properties in the ISA model (next commit), expose this property. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200907015535.827885-6-f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/char/serial: Rename I/O read/write trace eventsPhilippe Mathieu-Daudé2-4/+4
The serial_mm_read/write() handlers from the TYPE_SERIAL_MM device call the serial_ioport_read/write() handlers with shifted offset. When looking at the trace events from this MMIO device, it is confusing to read the accesses as I/O. Simplify using generic trace event names which make sense the various uses. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200907015535.827885-5-f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/char/serial: Remove old DEBUG_SERIAL commented codePhilippe Mathieu-Daudé1-11/+0
All useful DPRINTF() calls have been converted to trace events. Remove a pointless one in the IOEventHandler, and drop the DEBUG_SERIAL ifdef'ry. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200907015535.827885-4-f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/char/serial: Replace commented DPRINTF() by trace eventPhilippe Mathieu-Daudé2-3/+2
Convert the old debug PRINTF() call to display the UART baudrate to a trace event. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200907015535.827885-3-f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/char/serial: Assert serial_ioport_read/write offset fits 8 bytesPhilippe Mathieu-Daudé1-2/+2
The serial device has 8 registers, each 8-bit. The MemoryRegionOps 'serial_io_ops' is initialized with max_access_size=1, and all memory_region_init_io() callers correctly set the region size to 8 bytes: - serial_io_realize - serial_isa_realizefn - serial_pci_realize - multi_serial_pci_realize It is safe to assert the offset argument of serial_ioport_read() and serial_ioport_write() is always less than 8. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200907015535.827885-2-f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30hw/char/serial: Remove TYPE_SERIAL_IOPhilippe Mathieu-Daudé1-41/+0
TYPE_SERIAL_IO is a subset of TYPE_SERIAL_MM, and it is not used anymore. Remove it. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20200907011538.818996-3-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
generated by cgit v1.1 at 2024-10-01 21:05:44 +0000