aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2020-02-20Remove unnecessary cast when using the cpu_[physical]_memory APIPhilippe Mathieu-Daudé3-25/+18
This commit was produced with the included Coccinelle script scripts/coccinelle/exec_rw_const. Suggested-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-02-20Remove unnecessary cast when using the address_space APIPhilippe Mathieu-Daudé6-35/+30
This commit was produced with the included Coccinelle script scripts/coccinelle/exec_rw_const. Two lines in hw/net/dp8393x.c that Coccinelle produced that were over 80 characters were re-wrapped by hand. Suggested-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-02-20hw/net: Avoid casting non-const pointer, use address_space_write()Philippe Mathieu-Daudé2-4/+3
The NetReceive prototype gets a const buffer: typedef ssize_t (NetReceive)(NetClientState *, const uint8_t *, size_t); We already have the address_space_write() method to write a const buffer to an address space. Use it to avoid: hw/net/i82596.c: In function ‘i82596_receive’: hw/net/i82596.c:644:54: error: passing argument 4 of ‘address_space_rw’ discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers] This commit was produced with the included Coccinelle script scripts/coccinelle/exec_rw_const. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-02-20hw: Remove unnecessary cast when calling dma_memory_read()Philippe Mathieu-Daudé3-18/+10
Since its introduction in commit d86a77f8abb, dma_memory_read() always accepted void pointer argument. Remove the unnecessary casts. This commit was produced with the included Coccinelle script scripts/coccinelle/exec_rw_const. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> --- v4: Drop parenthesis when removing cast (Eric Blake)
2020-02-14Merge remote-tracking branch 'remotes/palmer/tags/riscv-for-master-5.0-sf2' ↵Peter Maydell6-4/+332
into staging RISC-V Patches for the 5.0 Soft Freeze, Part 2 This is a fairly light-weight pull request, but I wanted to send it out to avoid the Goldfish stuff getting buried as the next PR should contain the H extension implementation. As far as this PR goes, it contains: * The addition of syscon device tree nodes for reboot and poweroff, which allows Linux to control QEMU without an additional driver. The existing device was already compatible with the syscon interface. * A fix to our GDB stub to avoid confusing XLEN and FLEN, specifically useful for rv32id-based systems. * A device emulation for the Goldfish RTC device, a simple memory-mapped RTC. * The addition of the Goldfish RTC device to the RISC-V virt board. This passes "make check" and boots buildroot for me. # gpg: Signature made Mon 10 Feb 2020 21:28:04 GMT # gpg: using RSA key 2B3C3747446843B24A943A7A2E1319F35FBB1889 # gpg: issuer "palmer@dabbelt.com" # gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [unknown] # gpg: aka "Palmer Dabbelt <palmer@sifive.com>" [unknown] # gpg: aka "Palmer Dabbelt <palmerdabbelt@google.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 00CE 76D1 8349 60DF CE88 6DF8 EF4C A150 2CCB AB41 # Subkey fingerprint: 2B3C 3747 4468 43B2 4A94 3A7A 2E13 19F3 5FBB 1889 * remotes/palmer/tags/riscv-for-master-5.0-sf2: MAINTAINERS: Add maintainer entry for Goldfish RTC riscv: virt: Use Goldfish RTC device hw: rtc: Add Goldfish RTC device riscv: Separate FPU register size from core register size in gdbstub [v2] riscv/virt: Add syscon reboot and poweroff DT nodes Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-14Merge remote-tracking branch ↵Peter Maydell7-69/+222
'remotes/pmaydell/tags/pull-target-arm-20200213' into staging target-arm queue: * i.MX: Fix inverted sense of register bits in watchdog timer * i.MX: Add support for WDT on i.MX6 * arm/virt: cleanups to ACPI tables * Implement ARMv8.1-VMID16 extension * Implement ARMv8.1-PAN * Implement ARMv8.2-UAO * Implement ARMv8.2-ATS1E1 * ast2400/2500/2600: Wire up EHCI controllers * hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init * hw/arm/raspi: Clean up the board code # gpg: Signature made Thu 13 Feb 2020 14:40:34 GMT # 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-20200213: (46 commits) target/arm: Implement ARMv8.1-VMID16 extension hw/arm/raspi: Extract the cores count from the board revision hw/arm/raspi: Use a unique raspi_machine_class_init() method hw/arm/raspi: Extract the board model from the board revision hw/arm/raspi: Set default RAM size to size encoded in board revision hw/arm/raspi: Let class_init() directly call raspi_machine_init() hw/arm/raspi: Make board_rev a field of RaspiMachineClass hw/arm/raspi: Make machines children of abstract RaspiMachineClass hw/arm/raspi: Trivial code movement hw/arm/raspi: Extract the processor type from the board revision hw/arm/raspi: Extract the RAM size from the board revision hw/arm/raspi: Extract the version from the board revision hw/arm/raspi: Correct the board descriptions hw/arm/raspi: Use BCM2708 machine type with pre Device Tree kernels hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_init hw/arm: ast2600: Wire up EHCI controllers hw/arm: ast2400/ast2500: Wire up EHCI controllers target/arm: Enable ARMv8.2-UAO in -cpu max target/arm: Implement UAO semantics target/arm: Update MSR access to UAO ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13Merge remote-tracking branch 'remotes/kraxel/tags/vga-20200213-pull-request' ↵Peter Maydell3-2/+9
into staging qxl: introduce hardware revision 5 # gpg: Signature made Thu 13 Feb 2020 09:06:14 GMT # 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/vga-20200213-pull-request: qxl: introduce hardware revision 5 Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Extract the cores count from the board revisionPhilippe Mathieu-Daudé1-3/+16
The count of ARM cores is encoded in the board revision. Add a helper to extract the number of cores, and use it. This will be helpful when we add the Raspi0/1 that have a single core. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-14-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: tweaked commit message as suggested by Igor] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Use a unique raspi_machine_class_init() methodPhilippe Mathieu-Daudé1-25/+6
With the exception of the ignore_memory_transaction_failures flag set for the raspi2, both machine_class_init() methods are now identical. Merge them to keep a unique method. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20200208165645.15657-13-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Extract the board model from the board revisionPhilippe Mathieu-Daudé1-2/+16
The board revision encode the model type. Add a helper to extract the model, and use it. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-12-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Set default RAM size to size encoded in board revisionPhilippe Mathieu-Daudé1-2/+2
We added a helper to extract the RAM size from the board revision, and made board_rev a field of RaspiMachineClass. The class_init() can now use the helper to extract from the board revision the board-specific amount of RAM. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-11-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Let class_init() directly call raspi_machine_init()Philippe Mathieu-Daudé1-13/+3
raspi_machine_init() access to board_rev via RaspiMachineClass. raspi2_init() and raspi3_init() do nothing. Call raspi_machine_init directly. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20200208165645.15657-10-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Make board_rev a field of RaspiMachineClassPhilippe Mathieu-Daudé1-3/+14
We want to have a common class_init(). The only value that matters (and changes) is the board revision. Pass the board_rev as class_data to class_init(). Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-9-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Make machines children of abstract RaspiMachineClassPhilippe Mathieu-Daudé1-7/+49
QOM'ify RaspiMachineState. Now machines inherit of RaspiMachineClass. Cc: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20200208165645.15657-8-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Trivial code movementPhilippe Mathieu-Daudé1-3/+2
There is no point in creating the SoC object before allocating the RAM. Move the call to keep all the SoC-related calls together. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20200208165645.15657-7-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Extract the processor type from the board revisionPhilippe Mathieu-Daudé1-2/+16
The board revision encode the processor type. Add a helper to extract the type, and use it. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-6-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Extract the RAM size from the board revisionPhilippe Mathieu-Daudé1-3/+12
The board revision encode the amount of RAM. Add a helper to extract the RAM size, and use it. Since the amount of RAM is fixed (it is impossible to physically modify to have more or less RAM), do not allow sizes different than the one anounced by the manufacturer. Acked-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-5-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Extract the version from the board revisionPhilippe Mathieu-Daudé1-4/+27
The board revision encode the board version. Add a helper to extract the version, and use it. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-4-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Correct the board descriptionsPhilippe Mathieu-Daudé1-2/+2
We hardcode the board revision as 0xa21041 for the raspi2, and 0xa02082 for the raspi3: 166 static void raspi_init(MachineState *machine, int version) 167 { ... 194 int board_rev = version == 3 ? 0xa02082 : 0xa21041; These revision codes are for the 2B and 3B models, see: https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md Correct the board description. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200208165645.15657-3-f4bug@amsat.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm/raspi: Use BCM2708 machine type with pre Device Tree kernelsPhilippe Mathieu-Daudé1-3/+3
When booting without device tree, the Linux kernels uses the $R1 register to determine the machine type. The list of values is registered at [1]. There are two entries for the Raspberry Pi: - https://www.arm.linux.org.uk/developer/machines/list.php?mid=3138 name: MACH_TYPE_BCM2708 value: 0xc42 (3138) status: Active, not mainlined date: 15 Oct 2010 - https://www.arm.linux.org.uk/developer/machines/list.php?mid=4828 name: MACH_TYPE_BCM2835 value: 4828 status: Active, mainlined date: 6 Dec 2013 QEMU always used the non-mainlined type MACH_TYPE_BCM2708. The value 0xc43 is registered to 'MX51_GGC' (processor i.MX51), and 0xc44 to 'Western Digital Sharespace NAS' (processor Marvell 88F5182). The Raspberry Pi foundation bootloader only sets the BCM2708 machine type, see [2] or [3]: 133 9: 134 mov r0, #0 135 ldr r1, =3138 @ BCM2708 machine id 136 ldr r2, atags @ ATAGS 137 bx r4 U-Boot only uses MACH_TYPE_BCM2708 (see [4]): 25 /* 26 * 2835 is a SKU in a series for which the 2708 is the first or primary SoC, 27 * so 2708 has historically been used rather than a dedicated 2835 ID. 28 * 29 * We don't define a machine type for bcm2709/bcm2836 since the RPi Foundation 30 * chose to use someone else's previously registered machine ID (3139, MX51_GGC) 31 * rather than obtaining a valid ID:-/ 32 * 33 * For the bcm2837, hopefully a machine type is not needed, since everything 34 * is DT. 35 */ While the definition MACH_BCM2709 with value 0xc43 was introduced in a commit described "Add 2709 platform for Raspberry Pi 2" out of the mainline Linux kernel, it does not seem used, and the platform is introduced with Device Tree support anyway (see [5] and [6]). Remove the unused values (0xc43 introduced in commit 1df7d1f9303aef "raspi: add raspberry pi 2 machine" and 0xc44 in commit bade58166f4 "raspi: Raspberry Pi 3 support"), keeping only MACH_TYPE_BCM2708. [1] https://www.arm.linux.org.uk/developer/machines/ [2] https://github.com/raspberrypi/tools/blob/920c7ed2e/armstubs/armstub7.S#L135 [3] https://github.com/raspberrypi/tools/blob/49719d554/armstubs/armstub7.S#L64 [4] https://gitlab.denx.de/u-boot/u-boot/blob/v2015.04/include/configs/rpi-common.h#L18 [5] https://github.com/raspberrypi/linux/commit/d9fac63adac#diff-6722037d79570df5b392a49e0e006573R526 [6] http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-February/001268.html Cc: Zoltán Baldaszti <bztemail@gmail.com> Cc: Pekka Enberg <penberg@iki.fi> Cc: Stephen Warren <swarren@nvidia.com> Cc: Kshitij Soni <kshitij.soni@broadcom.com> Cc: Michael Chan <michael.chan@broadcom.com> Cc: Andrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20200208165645.15657-2-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/char/exynos4210_uart: Fix memleaks in exynos4210_uart_initChen Qun1-2/+3
It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments":{"typename":"exynos4210.uart"}}' ASAN shows memory leak stack: #1 0xfffd896d71cb in g_malloc0 (/lib64/libglib-2.0.so.0+0x571cb) #2 0xaaad270beee3 in timer_new_full /qemu/include/qemu/timer.h:530 #3 0xaaad270beee3 in timer_new /qemu/include/qemu/timer.h:551 #4 0xaaad270beee3 in timer_new_ns /qemu/include/qemu/timer.h:569 #5 0xaaad270beee3 in exynos4210_uart_init /qemu/hw/char/exynos4210_uart.c:677 #6 0xaaad275c8f4f in object_initialize_with_type /qemu/qom/object.c:516 #7 0xaaad275c91bb in object_new_with_type /qemu/qom/object.c:684 #8 0xaaad2755df2f in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:152 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200213025603.149432-1-kuhn.chenqun@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm: ast2600: Wire up EHCI controllersGuenter Roeck1-0/+23
Initialize EHCI controllers on AST2600 using the existing TYPE_PLATFORM_EHCI. After this change, booting ast2600-evb into Linux successfully instantiates a USB interface after the necessary changes are made to its devicetree files. ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-platform: EHCI generic platform driver ehci-platform 1e6a3000.usb: EHCI Host Controller ehci-platform 1e6a3000.usb: new USB bus registered, assigned bus number 1 ehci-platform 1e6a3000.usb: irq 25, io mem 0x1e6a3000 ehci-platform 1e6a3000.usb: USB 2.0 started, EHCI 1.00 usb usb1: Manufacturer: Linux 5.5.0-09825-ga0802f2d0ef5-dirty ehci_hcd usb 1-1: new high-speed USB device number 2 using ehci-platform Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-id: 20200207174548.9087-1-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13hw/arm: ast2400/ast2500: Wire up EHCI controllersGuenter Roeck1-0/+25
Initialize EHCI controllers on AST2400 and AST2500 using the existing TYPE_PLATFORM_EHCI. After this change, booting ast2500-evb into Linux successfully instantiates a USB interface. ehci-platform 1e6a3000.usb: EHCI Host Controller ehci-platform 1e6a3000.usb: new USB bus registered, assigned bus number 1 ehci-platform 1e6a3000.usb: irq 21, io mem 0x1e6a3000 ehci-platform 1e6a3000.usb: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.05 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200206183437.3979-1-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13arm/acpi: simplify the description of PCI _CRSHeyi Guo1-1/+0
The original code defines a named object for the resource template but then returns the resource template object itself; the resulted output is like below: Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, // Granularity 0x0000, // Range Minimum 0x00FF, // Range Maximum 0x0000, // Translation Offset 0x0100, // Length ,, ) ...... }) Return (ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, // Granularity 0x0000, // Range Minimum 0x00FF, // Range Maximum 0x0000, // Translation Offset 0x0100, // Length ,, ) ...... }) } So the named object "RBUF" is actually useless. The more natural way is to return RBUF instead, or simply drop RBUF definition. Choose the latter one to simplify the code. Signed-off-by: Heyi Guo <guoheyi@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200204014325.16279-7-guoheyi@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13arm/acpi: fix duplicated _UID of PCI interrupt link devicesHeyi Guo1-1/+1
Using _UID of 0 for all PCI interrupt link devices absolutely violates the spec. Simply increase one by one. Signed-off-by: Heyi Guo <guoheyi@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200204014325.16279-6-guoheyi@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13arm/acpi: fix PCI _PRT definitionHeyi Guo1-5/+5
The address field in each _PRT mapping package should be constructed with high word for device# and low word for function#, so it is wrong to use bus_no as the high word. The existing code adds a bunch useless entries with device #s above 31. Enumerate all possible slots (i.e. PCI_SLOT_MAX) instead. Signed-off-by: Heyi Guo <guoheyi@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200204014325.16279-5-guoheyi@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13arm/virt/acpi: remove _ADR from devices identified by _HIDHeyi Guo1-8/+0
According to ACPI spec, _ADR should be used for device on a bus that has a standard enumeration algorithm, but not for device which is on system bus and must be enumerated by OSPM. And it is not recommended to contain both _HID and _ADR in a single device. See ACPI 6.3, section 6.1, top of page 343: A device object must contain either an _HID object or an _ADR object, but should not contain both. (https://uefi.org/sites/default/files/resources/ACPI_6_3_May16.pdf) Signed-off-by: Heyi Guo <guoheyi@huawei.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200204014325.16279-4-guoheyi@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13arm/virt/acpi: remove meaningless sub device "RP0" from PCI0Heyi Guo1-4/+0
The sub device "RP0" under PCI0 in ACPI/DSDT does not contain any method or property other than "_ADR", so it is safe to remove it. Signed-off-by: Heyi Guo <guoheyi@huawei.com> Acked-by: "Michael S. Tsirkin" <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200204014325.16279-3-guoheyi@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13i.MX: Add support for WDT on i.MX6Roman Kapl1-0/+21
Uses the i.MX2 rudimentary watchdog driver. Signed-off-by: Roman Kapl <rka@sysgo.com> Message-id: 20200207095529.11309-1-rka@sysgo.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: removed accidental duplicate #include line] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13i.MX: Fix inverted register bits in wdt code.Roman Kapl1-1/+1
Documentation says for WDA '0: Assert WDOG output.' and for SRS '0: Assert system reset signal.'. Signed-off-by: Roman Kapl <rka@sysgo.com> Message-id: 20200207095409.11227-1-rka@sysgo.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-13qxl: introduce hardware revision 5Gerd Hoffmann3-2/+9
The only difference to hardware revision 4 is that the device doesn't switch to VGA mode in case someone happens to touch a VGA register, which should make things more robust in configurations with multiple vga devices. Swtiching back to VGA mode happens on reset, either full machine reset or qxl device reset (QXL_IO_RESET ioport command). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Message-id: 20200206074358.4274-1-kraxel@redhat.com
2020-02-12uas: fix super speed bMaxPacketSize0Gerd Hoffmann1-1/+1
For usb2 bMaxPacketSize0 is "n", for usb3 it is "1 << n", so it must be 9 not 64 ... rom "Universal Serial Bus 3.1 Specification": If the device is operating at Gen X speed, the bMaxPacketSize0 field shall be set to 09H indicating a 512-byte maximum packet. An Enhanced SuperSpeed device shall not support any other maximum packet sizes for the default control pipe (endpoint 0) control endpoint. We now announce a 512-byte maximum packet. Fixes: 89a453d4a5c ("uas-uas: usb3 streams") Reported-by: Benjamin David Lunt <fys@fysnet.net> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200117073716.31335-1-kraxel@redhat.com
2020-02-12usb-host: wait for cancel completeGerd Hoffmann1-8/+9
After canceling transfers call into libvirt so it can process the request, and wait for it to complete. Also cancel all pending transfers before exiting qemu. Buglink: https://bugzilla.redhat.com//show_bug.cgi?id=1749745 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200203114108.23952-1-kraxel@redhat.com
2020-02-10riscv: virt: Use Goldfish RTC deviceAnup Patel2-0/+17
We extend QEMU RISC-V virt machine by adding Goldfish RTC device to it. This will allow Guest Linux to sync it's local date/time with Host date/time via RTC device. Signed-off-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Acked-by: Palmer Dabbelt <palmer@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-02-10hw: rtc: Add Goldfish RTC deviceAnup Patel4-0/+293
This patch adds model for Google Goldfish virtual platform RTC device. We will be adding Goldfish RTC device to the QEMU RISC-V virt machine for providing real date-time to Guest Linux. The corresponding Linux driver for Goldfish RTC device is already available in upstream Linux. For now, VM migration support is available but untested for Goldfish RTC device. It will be hardened in-future when we implement VM migration for KVM RISC-V. Signed-off-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-02-10riscv/virt: Add syscon reboot and poweroff DT nodesAnup Patel1-4/+22
The SiFive test device found on virt machine can be used by generic syscon reboot and poweroff drivers available in Linux kernel. This patch updates FDT generation in virt machine so that Linux kernel can probe and use generic syscon drivers. Signed-off-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-02-10Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into ↵Peter Maydell1-1/+2
staging Pull request # gpg: Signature made Mon 10 Feb 2020 09:23:42 GMT # gpg: using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [full] # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" [full] # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * remotes/stefanha/tags/block-pull-request: hw/core: Allow setting 'virtio-blk-device.scsi' property on OSX host block: fix crash on zero-length unaligned write and read Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-10Merge remote-tracking branch 'remotes/gkurz/tags/9p-next-2020-02-08' into ↵Peter Maydell4-0/+56
staging 9p patches: - some more protocol sanity checks - qtest for readdir - Christian Schoenebeck now official reviewer # gpg: Signature made Sat 08 Feb 2020 08:38:10 GMT # gpg: using RSA key B4828BAF943140CEF2A3491071D4D5E5822F73D6 # gpg: Good signature from "Greg Kurz <groug@kaod.org>" [full] # gpg: aka "Gregory Kurz <gregory.kurz@free.fr>" [full] # gpg: aka "[jpeg image of size 3330]" [full] # Primary key fingerprint: B482 8BAF 9431 40CE F2A3 4910 71D4 D5E5 822F 73D6 * remotes/gkurz/tags/9p-next-2020-02-08: MAINTAINERS: 9pfs: Add myself as reviewer tests/virtio-9p: added readdir test hw/9pfs/9p-synth: added directory for readdir test 9pfs: validate count sent by client with T_readdir 9pfs: require msize >= 4096 tests/virtio-9p: add terminating null in v9fs_string_read() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-08hw/9pfs/9p-synth: added directory for readdir testChristian Schoenebeck2-0/+24
This will provide the following virtual files by the 9pfs synth driver: - /ReadDirDir/ReadDirFile99 - /ReadDirDir/ReadDirFile98 ... - /ReadDirDir/ReadDirFile1 - /ReadDirDir/ReadDirFile0 This virtual directory and its virtual 100 files will be used by the upcoming 9pfs readdir tests. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <5408c28c8de25dd575b745cef63bf785305ccef2.1579567020.git.qemu_oss@crudebyte.com> Signed-off-by: Greg Kurz <groug@kaod.org>
2020-02-089pfs: validate count sent by client with T_readdirChristian Schoenebeck1-0/+9
A good 9p client sends T_readdir with "count" parameter that's sufficiently smaller than client's initially negotiated msize (maximum message size). We perform a check for that though to avoid the server to be interrupted with a "Failed to encode VirtFS reply type 41" transport error message by bad clients. This count value constraint uses msize - 11, because 11 is the header size of R_readdir. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <3990d3891e8ae2074709b56449e96ab4b4b93b7d.1579567020.git.qemu_oss@crudebyte.com> [groug: added comment ] Signed-off-by: Greg Kurz <groug@kaod.org>
2020-02-089pfs: require msize >= 4096Christian Schoenebeck2-0/+23
A client establishes a session by sending a Tversion request along with a 'msize' parameter which client uses to suggest server a maximum message size ever to be used for communication (for both requests and replies) between client and server during that session. If client suggests a 'msize' smaller than 4096 then deny session by server immediately with an error response (Rlerror for "9P2000.L" clients or Rerror for "9P2000.u" clients) instead of replying with Rversion. So far any msize submitted by client with Tversion was simply accepted by server without any check. Introduction of some minimum msize makes sense, because e.g. a msize < 7 would not allow any subsequent 9p operation at all, because 7 is the size of the header section common by all 9p message types. A substantial higher value of 4096 was chosen though to prevent potential issues with some message types. E.g. Rreadlink may yield up to a size of PATH_MAX which is usually 4096, and like almost all 9p message types, Rreadlink is not allowed to be truncated by the 9p protocol. This chosen size also prevents a similar issue with Rreaddir responses (provided client always sends adequate 'count' parameter with Treaddir), because even though directory entries retrieval may be split up over several T/Rreaddir messages; a Rreaddir response must not truncate individual directory entries though. So msize should be large enough to return at least one directory entry with the longest possible file name supported by host. Most file systems support a max. file name length of 255. Largest known file name lenght limit would be currently ReiserFS with max. 4032 bytes, which is also covered by this min. msize value because 4032 + 35 < 4096. Furthermore 4096 is already the minimum msize of the Linux kernel's 9pfs client. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <8ceecb7fb9fdbeabbe55c04339349a36929fb8e3.1579567019.git.qemu_oss@crudebyte.com> Signed-off-by: Greg Kurz <groug@kaod.org>
2020-02-07hw/core: Allow setting 'virtio-blk-device.scsi' property on OSX hostPhilippe Mathieu-Daudé1-1/+2
Commit ed65fd1a2750 ("virtio-blk: switch off scsi-passthrough by default") changed the default value of the 'scsi' property of virtio-blk, which is only available on Linux hosts. It also added an unconditional compat entry for 2.4 or earlier machines. Trying to set this property on a pre-2.5 machine on OSX, we get: Unexpected error in object_property_find() at qom/object.c:1201: qemu-system-x86_64: -device virtio-blk-pci,id=scsi0,drive=drive0: can't apply global virtio-blk-device.scsi=true: Property '.scsi' not found Fix this error by marking the property optional. Fixes: ed65fd1a27 ("virtio-blk: switch off scsi-passthrough by default") Suggested-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20200207001404.1739-1-philmd@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-02-07stellaris: delay timer_new to avoid memleaksPan Nengyuan1-1/+6
There is a memory leak when we call 'device_list_properties' with typename = stellaris-gptm. It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments": {"typename": "stellaris-gptm"}}' This patch delay timer_new in realize to fix it. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200205070659.22488-4-pannengyuan@huawei.com Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-07stm32f2xx_timer: delay timer_new to avoid memleaksPan Nengyuan1-0/+5
There is a memory leak when we call 'device_list_properties' with typename = stm32f2xx_timer. It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments": {"typename": "stm32f2xx_timer"}}' This patch delay timer_new to fix this memleaks. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200205070659.22488-3-pannengyuan@huawei.com Cc: Alistair Francis <alistair@alistair23.me> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-07armv7m_systick: delay timer_new to avoid memleaksPan Nengyuan1-0/+6
There is a memory leak when we call 'device_list_properties' with typename = armv7m_systick. It's easy to reproduce as follow: virsh qemu-monitor-command vm1 --pretty '{"execute": "device-list-properties", "arguments": {"typename": "armv7m_systick"}}' This patch delay timer_new to fix this memleaks. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-id: 20200205070659.22488-2-pannengyuan@huawei.com Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-07bcm2835_dma: Re-initialize xlen in TD modeRene Stange1-1/+3
TD (two dimensions) DMA mode did not work, because the xlen variable has not been re-initialized before each additional ylen run through in bcm2835_dma_update(). Fix it. Signed-off-by: Rene Stange <rsta2@o2online.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-07bcm2835_dma: Fix the ylen loop in TD modeRene Stange1-2/+2
In TD (two dimensions) DMA mode ylen has to be increased by one after reading it from the TXFR_LEN register, because a value of zero has to result in one run through of the ylen loop. This has been tested on a real Raspberry Pi 3 Model B+. In the previous implementation the ylen loop was not passed at all for a value of zero. Signed-off-by: Rene Stange <rsta2@o2online.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-06hw/vfio: Move the IGD quirk code to a separate fileThomas Huth5-611/+642
The IGD quirk code defines a separate device, the so-called "vfio-pci-igd-lpc-bridge" which shows up as a user-creatable device in all QEMU binaries that include the vfio code. This is a little bit unfortunate for two reasons: First, this device is completely useless in binaries like qemu-system-s390x. Second we also would like to disable it in downstream RHEL which currently requires some extra patches there since the device does not have a proper Kconfig-style switch yet. So it would be good if the device could be disabled more easily, thus let's move the code to a separate file instead and introduce a proper Kconfig switch for it which gets only enabled by default if we also have CONFIG_PC_PCI enabled. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2020-02-06aspeed/i2c: Prevent uninitialized warningMiroslav Rezanina1-1/+1
Compiler reports uninitialized warning for cmd_flags variable. Adding NULL initialization to prevent this warning. Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <07957dcab31f65de3dd30efa91e6b9152ac79879.1579598240.git.mrezanin@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-02-06hw/i386/vmmouse: Fix crash when using the vmmouse on a machine without vmportThomas Huth1-0/+6
QEMU currently crashes when the user tries to use the "vmmouse" on a machine without vmport, e.g.: $ x86_64-softmmu/qemu-system-x86_64 -machine microvm -device vmmouse Segmentation fault (core dumped) or: $ x86_64-softmmu/qemu-system-x86_64 -device vmmouse -M pc,vmport=off Segmentation fault (core dumped) Let's avoid the crash by checking for the vmport device first. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20200129112954.4282-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
generated by cgit v1.1 at 2024-08-19 15:29:55 +0000