aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
2020-10-01Merge remote-tracking branch 'remotes/jsnow-gitlab/tags/ide-pull-request' ↵Peter Maydell
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 Snow
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 Snow
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 Snow
(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 Snow
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 Snow
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 Snow
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 Snow
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é
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 Maydell
'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é
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é
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é
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é
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é
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é
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é
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é
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é
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é
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 Maydell
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 Maydell
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 Maydell
'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 Pisa
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 Charvat
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 Charvat
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 Charvat
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 Charvat
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 Kuznetsov
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é
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é
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é
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 Qiang
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 Qiang
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 Fomichev
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é
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é
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é
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é
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é
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é
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é
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>
2020-09-30hw/mips/mipssim: Use MMIO serial device on fake ISA I/OPhilippe Mathieu-Daudé
The 'mipssim' is not a real hardware, it is a simulator. There is an ISA MMIO space mapped at 0x1fd00000, however this is not a real ISA bus (no ISA IRQ). So can not use the TYPE_ISA_SERIAL device... Instead we have been using a plain MMIO device, but named it IO. TYPE_SERIAL_IO is a subset of TYPE_SERIAL_MM, using regshift=0 and endianness=DEVICE_LITTLE_ENDIAN. Directly use the TYPE_SERIAL_MM device, enforcing the regshift/endianness values. 'regshift' default is already '0'. 'endianness' is meaningless for 8-bit accesses. This change breaks migration back compatibility, but this is not an issue for the mipssim machine. 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-2-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30numa: remove fixup numa_state->num_nodes to MAX_NODESIgor Mammedov
current code permits only nodeids in [0..MAX_NODES) range due to nodeid check in parse_numa_node() if (nodenr >= MAX_NODES) { error_setg(errp, "Max number of NUMA nodes reached: %" so subj fixup is not reachable, drop it. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200911084410.788171-4-imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30numa: drop support for '-numa node' (without memory specified)Igor Mammedov
it was deprecated since 4.1 commit 4bb4a2732e (numa: deprecate implict memory distribution between nodes) Users of existing VMs, wishing to preserve the same RAM distribution, should configure it explicitly using ``-numa node,memdev`` options. Current RAM distribution can be retrieved using HMP command `info numa` and if separate memory devices (pc|nv-dimm) are present use `info memory-device` and subtract device memory from output of `info numa`. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200911084410.788171-2-imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30acpi: i386: Move VMBus DSDT entry to SBJon Doron
Signed-off-by: Jon Doron <arilou@gmail.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200715084326.678715-2-arilou@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30vhost-scsi: support inflight io trackLi Feng
Qemu will send GET_INFLIGHT_FD and SET_INFLIGH_FD to backend, and the backend setup the inflight memory to track the io. Change-Id: I805d6189996f7a1b44c65f0b12ef7473b1789510 Signed-off-by: Li Feng <fengli@smartx.com> Message-Id: <20200909122021.1055174-1-fengli@smartx.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-09-30acpi/gpex: no reason to use a method for _CRSGerd Hoffmann
... just to return something which is constant anyway. - Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings - { - Return (ResourceTemplate () - { - WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, [ ... ] + Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings + { + WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, [ ... ] Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200928104256.9241-12-kraxel@redhat.com
2020-09-30microvm/pcie: add 64bit mmio windowGerd Hoffmann
Place the 64bit window at the top of the physical address space, assign 25% of the avaiable address space. Force cpu.host-phys-bits=on for microvm machine typs so this actually works reliable. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200928104256.9241-7-kraxel@redhat.com
2020-09-30microvm: add pcie supportGerd Hoffmann
Uses the existing gpex device which is also used as pcie host bridge on arm/aarch64. For now only a 32bit mmio window and no ioport support. It is disabled by default, use "-machine microvm,pcie=on" to enable. ACPI support must be enabled too because the bus is declared in the DSDT table. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200928104256.9241-6-kraxel@redhat.com
generated by cgit v1.2.3 (git 2.26.2) at 2025-01-23 00:22:10 +0000