summary refs log tree commit diff stats
path: root/hw/hyperv/hyperv_testdev.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2020-06-23qdev: Make qdev_prop_set_drive() match the other helpersMarkus Armbruster32-59/+74
qdev_prop_set_drive() can fail. None of the other qdev_prop_set_FOO() can; they abort on error. To clean up this inconsistency, rename qdev_prop_set_drive() to qdev_prop_set_drive_err(), and create a qdev_prop_set_drive() that aborts on error. Coccinelle script to update callers: @ depends on !(file in "hw/core/qdev-properties-system.c")@ expression dev, name, value; symbol error_abort; @@ - qdev_prop_set_drive(dev, name, value, &error_abort); + qdev_prop_set_drive(dev, name, value); @@ expression dev, name, value, errp; @@ - qdev_prop_set_drive(dev, name, value, errp); + qdev_prop_set_drive_err(dev, name, value, errp); Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200622094227.1271650-14-armbru@redhat.com>
2020-06-23qdev: Reject chardev property overrideMarkus Armbruster1-0/+8
qdev_prop_set_chr() screws up when the property already has a non-null value: it neglects to release the old value. Both the old and the new backend become attached to the same device. Unlike for block devices (see previous commit), this can't be observed from the monitor (I think). Example: -serial null -chardev null,id=chr0 -global isa-serial.chardev=chr0 Special case: attempting to use the same backend both times crashes: $ qemu-system-x86_64 --nodefaults -serial null -global isa-serial.chardev=serial0 Unexpected error in qemu_chr_fe_init() at /work/armbru/qemu/chardev/char-fe.c:220: qemu-system-x86_64: Device 'serial0' is in use Aborted (core dumped) Yet another example: -device with multiple chardev=... (but not device_add, which silently drops all but the last duplicate property). Perhaps chardev property override could be made to work. Perhaps it should. I can't afford the time to figure this out now. What I can do reject usage that leaves backends in unhealthy states. For what it's worth, we've long done the same for netdev properties. Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200622094227.1271650-13-armbru@redhat.com>
2020-06-23qdev: Reject drive property overrideMarkus Armbruster2-85/+11
qdev_prop_set_drive() screws up when the property already has a non-null value: it neglects to release the old value. Both the old and the new backend become attached to the same device. Example (taken from iotest 172): -fda ... -drive if=none,... -global floppy.drive=none0. Special case: attempting to use the same backend both times fails. Example (also from iotest 172): -fda ... -global floppy.drive=floppy0. Yet another example: -device with multiple drive=... (but not device_add, which silently drops all but the last duplicate property). Perhaps drive property override could be made to work. Perhaps it should. I can't afford the time to figure this out now. What I can do is reject usage that leaves backends in unhealthy states. For what it's worth, we've long done the same for netdev properties. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200622094227.1271650-12-armbru@redhat.com>
2020-06-23qdev: Improve netdev property override error a bitMarkus Armbruster3-3/+46
qdev_prop_set_netdev() fails when the property already has a non-null value. Seems to go back to commit 30c367ed44 "qdev-properties-system.c: Allow vlan or netdev for -device, not both", v1.7.0. Board code doesn't expect failure, and crashes: $ qemu-system-x86_64 --nodefaults -nic user -netdev user,id=nic0 -global e1000.netdev=nic0 Unexpected error in error_set_from_qdev_prop_error() at /work/armbru/qemu/hw/core/qdev-properties.c:1101: qemu-system-x86_64: Property 'e1000.netdev' doesn't take value '__org.qemu.nic0 ' Aborted (core dumped) -device and device_add handle the failure: $ qemu-system-x86_64 -nodefaults -netdev user,id=net0 -netdev user,id=net1 -device e1000,netdev=net0,netdev=net1 qemu-system-x86_64: -device e1000,netdev=net0,netdev=net1: Property 'e1000.netdev' doesn't take value 'net1' $ qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -netdev user,id=net0 -netdev user,id=net1 -global e1000.netdev=net0 QEMU 5.0.50 monitor - type 'help' for more information (qemu) qemu-system-x86_64: warning: netdev net0 has no peer qemu-system-x86_64: warning: netdev net1 has no peer device_add e1000,netdev=net1 Error: Property 'e1000.netdev' doesn't take value 'net1' Perhaps netdev property override could be made to work. Perhaps it should. I'm not the right guy to figure this out. What I can do is improve the error message a bit: (qemu) device_add e1000,netdev=net1 Error: -global e1000.netdev=... conflicts with netdev=net1 Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200622094227.1271650-11-armbru@redhat.com>
2020-06-23qdev: Eliminate get_pointer(), set_pointer()Markus Armbruster1-60/+35
We stopped using get_pointer() and set_pointer() for netdev in commit 23120b13c6 "net: don't use set/get_pointer() in set/get_netdev()" (v2.3.0), and for chardev in commit becdfa00cf "char: replace PROP_CHR with CharBackend" (v2.8.0). With only the drive user left, they're not helpful anymore. Eliminate. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200622094227.1271650-10-armbru@redhat.com>
2020-06-23blockdev: Deprecate -drive with bogus interface typeMarkus Armbruster4-2/+43
Drives with interface types other than if=none are for onboard devices. Unfortunately, any such drives the board doesn't pick up can still be used with -device, like this: $ qemu-system-x86_64 -nodefaults -display none -S -drive if=floppy,id=bogus,unit=7 -device ide-cd,drive=bogus -monitor stdio QEMU 5.0.50 monitor - type 'help' for more information (qemu) info block bogus: [not inserted] Attached to: /machine/peripheral-anon/device[0] Removable device: not locked, tray closed (qemu) info qtree bus: main-system-bus type System [...] bus: ide.1 type IDE dev: ide-cd, id "" ---> drive = "bogus" [...] unit = 0 (0x0) [...] This kind of abuse has always worked. Deprecate it: qemu-system-x86_64: -drive if=floppy,id=bogus,unit=7: warning: bogus if=floppy is deprecated, use if=none Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200622094227.1271650-9-armbru@redhat.com>
2020-06-23docs/qdev-device-use.txt: Update section "Default Devices"Markus Armbruster1-2/+2
Resynchronize the table of default device suppressions with vl.c's default_list[]. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200622094227.1271650-8-armbru@redhat.com>
2020-06-23fdc: Deprecate configuring floppies with -global isa-fdcMarkus Armbruster4-9/+77
Deprecate -global isa-fdc.driveA=... -global isa-fdc.driveB=... in favour of -device floppy,unit=0,drive=... -device floppy,unit=1,drive=... Same for the other floppy controller devices. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: John Snow <jsnow@redhat.com> Message-Id: <20200622094227.1271650-7-armbru@redhat.com>
2020-06-23fdc: Open-code fdctrl_init_isa()Markus Armbruster3-17/+6
Helper function fdctrl_init_isa() is less than helpful: one of three places creating "isa-fdc" devices use it. Open-code it there, and drop the function. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200622094227.1271650-6-armbru@redhat.com>
2020-06-23fdc: Reject clash between -drive if=floppy and -global isa-fdcMarkus Armbruster6-159/+71
The floppy controller devices desugar their drive properties into floppy devices (since commit a92bd191a4 "fdc: Move qdev properties to FloppyDrive", v2.8.0). This involves some bad magic in fdctrl_connect_drives(), and exists for backward compatibility. The functions for boards to create floppy controller devices fdctrl_init_isa(), fdctrl_init_sysbus(), and sun4m_fdctrl_init() desugar -drive if=floppy to these floppy controller drive properties. If you use both -drive if=floppy (or its -fda / -fdb sugar) and -global isa-fdc for the same floppy device, -global silently loses the conflict, and both backends involved end up with the floppy device frontend attached, as demonstrated by iotest 172 (see commit before previous). This is wrong. Desugar -drive if=floppy straight to floppy devices instead, with helper fdctrl_init_drives(). The conflict now gets rejected cleanly: first, fdctrl_connect_drives() creates the floppy for the controller's property, then fdctrl_init_drives() attempts to create the floppy for -drive if=floppy, but fails because the unit is already in use. Output of iotest 172 changes in three ways: 1. The clash gets rejected. 2. In one test case, "info qtree" has the floppy devices swapped, and "info block" has their QOM paths swapped. This is because the floppy device for -fda now gets created after the one for -global isa-fdc.driveB. 3. The error message for -global floppy.drive=floppy0 changes. Before the patch, we set isa-fdc.driveA to -fda's block backend, then create the floppy device for it, then move the backend from isa-fdc.driveA to floppy.drive. Floppy creation fails when applying -global floppy.drive=floppy0, because floppy0 is still attached to isa-fdc. After the patch, we create the floppy for -fda, then set its drive property to floppy0. Now floppy creation succeeds, but setting the drive property fails, because -global already set it. Yes, this is exasperatingly complicated. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200622094227.1271650-5-armbru@redhat.com>
2020-06-23iotests/172: Cover -global floppy.drive=...Markus Armbruster2-0/+141
Use of -global to set a default backend for non-singleton devices is a bad idea. But as long as we permit it, we better test it. Test output demonstrates we screw up when -global floppy clashes with -fda or with -device floppy: according to "info qtree", only the latter backend is attached, but according to "info block", both are. Here's the clash with -device: Testing: -drive if=none,file=TEST_DIR/t.qcow2 -drive if=none,file=TEST_DIR/t.qcow2.2 -global floppy.drive=none0 -device floppy,drive=none1,unit=0 dev: isa-fdc, id "" [...] driveA = "" driveB = "" [...] bus: floppy-bus.0 type floppy-bus dev: floppy, id "" unit = 0 (0x0) ---> drive = "none1" [...] none0 (NODE_NAME): TEST_DIR/t.qcow2 (qcow2) ---> Attached to: /machine/peripheral-anon/device[0] Cache mode: writeback none1 (NODE_NAME): TEST_DIR/t.qcow2.2 (qcow2) ---> Attached to: /machine/peripheral-anon/device[0] Removable device: not locked, tray closed Cache mode: writeback /machine/peripheral-anon/device[0] is the floppy created with -device. Test output further demonstrates the "Drive 'FOO' is already in use because it has been automatically connected to another device" error message can be misleading. With '-fda "" -global floppy.drive=floppy0', it's in use because -global reuses -fda's backend. There is no other device involved. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200622094227.1271650-4-armbru@redhat.com>
2020-06-23iotests/172: Cover empty filename and multiple use of drivesMarkus Armbruster2-0/+62
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200622094227.1271650-3-armbru@redhat.com>
2020-06-23iotests/172: Include "info block" in test outputMarkus Armbruster2-2/+489
The additional output demonstrates we screw up when -global isa-fdc clashes with -drive if=floppy or its sugared forms: according to "info qtree", only the latter backend is attached, but according to "info block", both are. For instance: Testing: -fda TEST_DIR/t.qcow2 -drive if=none,file=TEST_DIR/t.qcow2.2 -global isa-fdc.driveA=none0 dev: isa-fdc, id "" [...] driveA = "" driveB = "" [...] bus: floppy-bus.0 type floppy-bus dev: floppy, id "" unit = 0 (0x0) ---> drive = "floppy0" [...] floppy0 (NODE_NAME): TEST_DIR/t.qcow2 (qcow2) ---> Attached to: /machine/unattached/device[15] Removable device: not locked, tray closed Cache mode: writeback none0 (NODE_NAME): TEST_DIR/t.qcow2.2 (qcow2) ---> Attached to: /machine/unattached/device[14] Cache mode: writeback /machine/unattached/device[15] is floppy, and /machine/unattached/device[14] is isa-fdc. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200622094227.1271650-2-armbru@redhat.com>
2020-06-21tests/acceptance: record/replay tests with advcal imagesPavel Dovgalyuk1-0/+108
This patch adds more record/replay tests with kernel images. Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> Tested-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <159073592589.20809.5156301499042635614.stgit@pasha-ThinkPad-X280> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> [PMD: Use os.path.join(), add avocado 'cpu' tags] Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-06-21tests/acceptance: add record/replay test for m68kPavel Dovgalyuk1-0/+18
This patch adds a test for record/replay of the kernel image boot for m68k platform. Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> Tested-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <159073592033.20809.1838967871297177313.stgit@pasha-ThinkPad-X280> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-06-21tests/acceptance: add record/replay test for ppc64Pavel Dovgalyuk1-0/+16
This patch adds a test for record/replay of the kernel image boot for ppc64 platform. Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> Tested-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <159073591363.20809.15658672985367330140.stgit@pasha-ThinkPad-X280> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-06-21tests/acceptance: add record/replay test for armPavel Dovgalyuk1-0/+48
This patch adds a test for record/replay of the kernel image boot for two different arm platforms. Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> Tested-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <159073590785.20809.17654573764167037499.stgit@pasha-ThinkPad-X280> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-06-21tests/acceptance: add record/replay test for aarch64Pavel Dovgalyuk1-0/+19
This patch adds a test for record/replay of the kernel image boot for aarch64 platform. Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> Tested-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <159073590231.20809.9842179251741585482.stgit@pasha-ThinkPad-X280> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-06-21tests/acceptance: add kernel record/replay test for x86_64Pavel Dovgalyuk1-0/+18
This patch adds a test for record/replay an execution of x86_64 machine. Execution scenario includes simple kernel boot, which allows testing basic hardware interaction in RR mode. Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> Tested-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <159073589656.20809.14010247947948822435.stgit@pasha-ThinkPad-X280> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> [PMD: Skip test_x86_64_pc on Travis-CI] Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-06-21tests/acceptance: add base class record/replay kernel testsPavel Dovgalyuk2-0/+74
This patch adds a base for testing kernel boot recording and replaying. Each test has the phase of recording and phase of replaying. Virtual machines just boot the kernel and do not interact with the network. Structure and image links for the tests are borrowed from boot_linux_console.py Testing controls the message pattern at the end of the kernel boot for both record and replay modes. In replay mode QEMU is also intended to finish the execution automatically. Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> Tested-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <159073589099.20809.14078431743098373301.stgit@pasha-ThinkPad-X280> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> [PMD: Keep imports sorted alphabetically] Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-06-21MAINTAINERS: Add an entry to review Avocado based acceptance testsPhilippe Mathieu-Daudé1-0/+8
Acceptance tests can test any piece of the QEMU codebase. As such, the directory holding them does not belong to a specific subsystem with designated maintainers. Each subsystem covered by a test is welcomed to add the test path to its section. See for example commits 71b290e70, b11785ca2 or 5d480ddde. Add an entry for to allow reviewers to be notified when acceptance / integration tests are added or modified. The designated reviewers are not maintainers, subsystem maintainers are expected to merge their tests. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Cleber Rosa <crosa@redhat.com> Message-Id: <20200129212345.20547-30-philmd@redhat.com> Message-Id: <20200605165656.17578-1-philmd@redhat.com>
2020-06-19qht: Fix threshold rate calculationRichard Henderson1-1/+2
tests/qht-bench.c:287:29: error: implicit conversion from 'unsigned long' to 'double' changes value from 18446744073709551615 to 18446744073709551616 [-Werror,-Wimplicit-int-float-conversion] *threshold = rate * UINT64_MAX; ~ ^~~~~~~~~~ Fix this by splitting the 64-bit constant into two halves, each of which is individually perfectly representable, the sum of which produces the correct arithmetic result. This is very likely just a sticking plaster over some underlying incorrect code, but it will suppress the warning for the moment. Cc: Emilio G. Cota <cota@braap.org> Reported-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-06-19hw/riscv: sifive_u: Add a dummy DDR memory controller deviceBin Meng2-0/+5
It is enough to simply map the SiFive FU540 DDR memory controller into the MMIO space using create_unimplemented_device(), to make the upstream U-Boot v2020.07 DDR memory initialization codes happy. Note we do not generate device tree fragment for the DDR memory controller. Since the controller data in device tree consumes a very large space (see fu540-hifive-unleashed-a00-ddr.dtsi in the U-Boot source), and it is only needed by U-Boot SPL but not any operating system, we choose not to generate the fragment here. This also means when testing with U-Boot SPL, the device tree has to come from U-Boot SPL itself, but not the one generated by QEMU on the fly. The memory has to be set to 8GiB to match the real HiFive Unleashed board when invoking QEMU (-m 8G). With this commit, QEMU can boot U-Boot SPL built for SiFive FU540 all the way up to loading U-Boot proper from MMC: $ qemu-system-riscv64 -nographic -M sifive_u,msel=6 -m 8G -bios u-boot-spl.bin U-Boot SPL 2020.07-rc3-00208-g88bd5b1 (Jun 08 2020 - 20:16:10 +0800) Trying to boot from MMC1 Unhandled exception: Load access fault EPC: 0000000008009be6 TVAL: 0000000010050014 The above exception is expected because QSPI is unsupported yet. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1592268641-7478-6-git-send-email-bmeng.cn@gmail.com Message-Id: <1592268641-7478-6-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_u: Sort the SoC memmap table entriesBin Meng1-2/+2
Move the flash and DRAM to the end of the SoC memmap table. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1592268641-7478-5-git-send-email-bmeng.cn@gmail.com Message-Id: <1592268641-7478-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_u: Support different boot source per MSEL pin stateBin Meng2-8/+37
SiFive FU540 SoC supports booting from several sources, which are controlled using the Mode Select (MSEL[3:0]) pins on the chip. Typically, the boot process runs through several stages before it begins execution of user-provided programs. The SoC supports booting from memory-mapped QSPI flash, which is how start_in_flash property is used for at present. This matches MSEL = 1 configuration (QSPI0). Typical booting flows involve the Zeroth Stage Boot Loader (ZSBL). It's not necessary for QEMU to implement the full ZSBL ROM codes, because we know ZSBL downloads the next stage program into the L2 LIM at address 0x8000000 and executes from there. We can bypass the whole ZSBL execution and use "-bios" to load the next stage program directly if MSEL indicates a ZSBL booting flow. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1592268641-7478-4-git-send-email-bmeng.cn@gmail.com Message-Id: <1592268641-7478-4-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive: Change SiFive E/U CPU reset vector to 0x1004Bin Meng3-15/+17
Per the SiFive manual, all E/U series CPU cores' reset vector is at 0x1004. Update our codes to match the hardware. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1592268641-7478-3-git-send-email-bmeng.cn@gmail.com Message-Id: <1592268641-7478-3-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19target/riscv: Rename IBEX CPU init routineBin Meng1-2/+2
Current IBEX CPU init routine name seems to be too generic. Since it uses a different reset vector from the generic one, it merits a dedicated name. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1592268641-7478-2-git-send-email-bmeng.cn@gmail.com Message-Id: <1592268641-7478-2-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_u: Add a new property msel for MSEL pin stateBin Meng2-0/+8
On SiFive FU540 SoC, the value stored at physical address 0x1000 stores the MSEL pin state that is used to control the next boot location that ROM codes jump to. Add a new property msel to sifive_u machine for this. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1591625864-31494-12-git-send-email-bmeng.cn@gmail.com Message-Id: <1591625864-31494-12-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_u: Rename serial property get/set functions to a generic nameBin Meng1-6/+8
In prepration to add more properties to this machine, rename the existing serial property get/set functions to a generic name. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1591625864-31494-11-git-send-email-bmeng.cn@gmail.com Message-Id: <1591625864-31494-11-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_u: Add reset functionalityBin Meng1-1/+23
The HiFive Unleashed board wires GPIO pin#10 to the input of the system reset signal. Let's set up the GPIO pin#10 and insert a "gpio-restart" device tree node so that reboot is now functional with QEMU 'sifive_u' machine. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1591625864-31494-10-git-send-email-bmeng.cn@gmail.com Message-Id: <1591625864-31494-10-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_gpio: Do not blindly trigger output IRQsBin Meng1-1/+3
At present the GPIO output IRQs are triggered each time any GPIO register is written. However this is not correct. We should only trigger the output IRQ when the pin is configured as output enable. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1591625864-31494-9-git-send-email-bmeng.cn@gmail.com Message-Id: <1591625864-31494-9-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_u: Hook a GPIO controllerBin Meng2-2/+60
SiFive FU540 SoC integrates a GPIO controller with 16 GPIO lines. This hooks the exsiting SiFive GPIO model to the SoC, and adds its device tree data as well. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1591625864-31494-8-git-send-email-bmeng.cn@gmail.com Message-Id: <1591625864-31494-8-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_gpio: Add a new 'ngpio' propertyBin Meng2-11/+22
Add a new property to represent the number of GPIO pins supported by the GPIO controller. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1591625864-31494-7-git-send-email-bmeng.cn@gmail.com Message-Id: <1591625864-31494-7-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_gpio: Clean up the codesBin Meng2-11/+9
Do various minor clean-ups to the exisiting codes for: - coding convention conformance - remove unnecessary blank lines - spell SiFive correctly Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1591625864-31494-6-git-send-email-bmeng.cn@gmail.com Message-Id: <1591625864-31494-6-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_u: Generate device tree node for OTPBin Meng1-0/+11
Upstream U-Boot v2020.07 codes switch to access SiFive FU540 OTP based on device tree information. Let's generate the device tree node for OTP. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1591625864-31494-5-git-send-email-bmeng.cn@gmail.com Message-Id: <1591625864-31494-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_u: Simplify the GEM IRQ connect code a little bitBin Meng1-6/+1
There is no need to retrieve all PLIC IRQ information in order to just connect the GEM IRQ. Use qdev_get_gpio_in() directly like what is done for other peripherals. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1591625864-31494-4-git-send-email-bmeng.cn@gmail.com Message-Id: <1591625864-31494-4-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: opentitan: Remove the riscv_ prefix of the machine* and soc* functionsBin Meng1-15/+14
This was done in the virt & sifive_u codes, but opentitan codes were missed. Remove the riscv_ prefix of the machine* and soc* functions. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1591625864-31494-3-git-send-email-bmeng.cn@gmail.com Message-Id: <1591625864-31494-3-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19hw/riscv: sifive_e: Remove the riscv_ prefix of the machine* and soc* functionsBin Meng1-12/+12
This was done in the virt & sifive_u codes, but sifive_e codes were missed. Remove the riscv_ prefix of the machine* and soc* functions. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1591625864-31494-2-git-send-email-bmeng.cn@gmail.com Message-Id: <1591625864-31494-2-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19target/riscv: Use a smaller guess size for no-MMU PMPAlistair Francis1-5/+9
Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com>
2020-06-19riscv/opentitan: Connect the UART deviceAlistair Francis2-2/+36
Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2020-06-19riscv/opentitan: Connect the PLIC deviceAlistair Francis2-2/+15
Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2020-06-19hw/intc: Initial commit of lowRISC Ibex PLICAlistair Francis4-0/+327
The Ibex core contains a PLIC that although similar to the RISC-V spec is not RISC-V spec compliant. This patch implements a Ibex PLIC in a somewhat generic way. As the current RISC-V PLIC needs tidying up, my hope is that as the Ibex PLIC move towards spec compliance this PLIC implementation can be updated until it can replace the current PLIC. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-06-19hw/char: Initial commit of Ibex UARTAlistair Francis5-0/+609
This is the initial commit of the Ibex UART device. Serial TX is working, while RX has been implemeneted but untested. This is based on the documentation from: https://docs.opentitan.org/hw/ip/uart/doc/ Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: LIU Zhiwei<zhiwei_liu@c-sky.com>
2020-06-19riscv/opentitan: Fix the ROM sizeAlistair Francis1-1/+2
Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reported-by: Damien Hedde <damien.hedde@greensocs.com>
2020-06-19target/riscv: Implement checks for hfenceAlistair Francis3-26/+24
Call the helper_hyp_tlb_flush() function on hfence instructions which will generate an illegal insruction execption if we don't have permission to flush the Hypervisor level TLBs. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2020-06-19target/riscv: Move the hfence instructions to the rvh decodeAlistair Francis4-41/+63
Also correct the name of the VVMA instruction. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2020-06-19target/riscv: Report errors validating 2nd-stage PTEsAlistair Francis1-2/+7
Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2020-06-19target/riscv: Set access as data_load when validating stage-2 PTEsAlistair Francis1-1/+1
Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2020-06-19riscv: Keep the CPU init routine names consistentBin Meng1-4/+4
Adding a _ to keep some consistency among the CPU init routines. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1591837729-27486-4-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-19riscv: Generalize CPU init routine for the imacu CPUBin Meng1-21/+10
There is no need to have two functions that have almost the same codes for 32-bit and 64-bit imacu CPUs. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1591837729-27486-3-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>