summary refs log tree commit diff stats
path: root/scripts/tracetool/backend/dtrace.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2018-03-09memory: fix flatview_access_valid RCU read lock/unlock imbalancePaolo Bonzini1-1/+0
Fixes: 11e732a5ed46903f997985bed4c3767ca28a7eb6 Reported-by: Cornelia Huck <cohuck@redhat.com> Reported-by: luigi burdo <intermediadc@hotmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Cornelia Huck <cohuck@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Message-id: 20180307130238.19358-1-pbonzini@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-09softfloat: fix crash on int conversion of SNaNStef O'Rear1-0/+4
Signed-off-by: Stef O'Rear <sorear2@gmail.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-08vl: introduce vm_shutdown()Stefan Hajnoczi5-46/+18
Commit 00d09fdbbae5f7864ce754913efc84c12fdf9f1a ("vl: pause vcpus before stopping iothreads") and commit dce8921b2baaf95974af8176406881872067adfa ("iothread: Stop threads before main() quits") tried to work around the fact that emulation was still active during termination by stopping iothreads. They suffer from race conditions: 1. virtio_scsi_handle_cmd_vq() racing with iothread_stop_all() hits the virtio_scsi_ctx_check() assertion failure because the BDS AioContext has been modified by iothread_stop_all(). 2. Guest vq kick racing with main loop termination leaves a readable ioeventfd that is handled by the next aio_poll() when external clients are enabled again, resulting in unwanted emulation activity. This patch obsoletes those commits by fully disabling emulation activity when vcpus are stopped. Use the new vm_shutdown() function instead of pause_all_vcpus() so that vm change state handlers are invoked too. Virtio devices will now stop their ioeventfds, preventing further emulation activity after vm_stop(). Note that vm_stop(RUN_STATE_SHUTDOWN) cannot be used because it emits a QMP STOP event that may affect existing clients. It is no longer necessary to call replay_disable_events() directly since vm_shutdown() does so already. Drop iothread_stop_all() since it is no longer used. Cc: Fam Zheng <famz@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 20180307144205.20619-5-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-03-08virtio-scsi: fix race between .ioeventfd_stop() and vq handlerStefan Hajnoczi1-4/+5
If the main loop thread invokes .ioeventfd_stop() just as the vq handler function begins in the IOThread then the handler may lose the race for the AioContext lock. By the time the vq handler is able to acquire the AioContext lock the ioeventfd has already been removed and the handler isn't supposed to run anymore! Use the new aio_wait_bh_oneshot() function to perform ioeventfd removal from within the IOThread. This way no races with the vq handler are possible. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 20180307144205.20619-4-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-03-08virtio-blk: fix race between .ioeventfd_stop() and vq handlerStefan Hajnoczi1-7/+17
If the main loop thread invokes .ioeventfd_stop() just as the vq handler function begins in the IOThread then the handler may lose the race for the AioContext lock. By the time the vq handler is able to acquire the AioContext lock the ioeventfd has already been removed and the handler isn't supposed to run anymore! Use the new aio_wait_bh_oneshot() function to perform ioeventfd removal from within the IOThread. This way no races with the vq handler are possible. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 20180307144205.20619-3-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-03-08block: add aio_wait_bh_oneshot()Stefan Hajnoczi2-0/+44
Sometimes it's necessary for the main loop thread to run a BH in an IOThread and wait for its completion. This primitive is useful during startup/shutdown to synchronize and avoid race conditions. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 20180307144205.20619-2-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-03-08s390x/virtio: Convert virtio-ccw from *_exit to *_unrealizeNia Alarie2-18/+18
Signed-off-by: Nia Alarie <nia.alarie@gmail.com> Message-Id: <20180307162958.11232-1-nia.alarie@gmail.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08virtio-blk: dataplane: Don't batch notifications if EVENT_IDX is presentSergio Lopez1-2/+13
Commit 5b2ffbe4d99843fd8305c573a100047a8c962327 ("virtio-blk: dataplane: notify guest as a batch") deferred guest notification to a BH in order batch notifications, with purpose of avoiding flooding the guest with interruptions. This optimization came with a cost. The average latency perceived in the guest is increased by a few microseconds, but also when multiple IO operations finish at the same time, the guest won't be notified until all completions from each operation has been run. On the contrary, virtio-scsi issues the notification at the end of each completion. On the other hand, nowadays we have the EVENT_IDX feature that allows a better coordination between QEMU and the Guest OS to avoid sending unnecessary interruptions. With this change, virtio-blk/dataplane only batches notifications if the EVENT_IDX feature is not present. Some numbers obtained with fio (ioengine=sync, iodepth=1, direct=1): - Test specs: * fio-3.4 (ioengine=sync, iodepth=1, direct=1) * qemu master * virtio-blk with a dedicated iothread (default poll-max-ns) * backend: null_blk nr_devices=1 irqmode=2 completion_nsec=280000 * 8 vCPUs pinned to isolated physical cores * Emulator and iothread also pinned to separate isolated cores * variance between runs < 1% - Not patched * numjobs=1: lat_avg=327.32 irqs=29998 * numjobs=4: lat_avg=337.89 irqs=29073 * numjobs=8: lat_avg=342.98 irqs=28643 - Patched: * numjobs=1: lat_avg=323.92 irqs=30262 * numjobs=4: lat_avg=332.65 irqs=29520 * numjobs=8: lat_avg=335.54 irqs=29323 Signed-off-by: Sergio Lopez <slp@redhat.com> Message-id: 20180307114459.26636-1-slp@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-03-08README: Fix typo 'git-publish'Fam Zheng1-1/+1
Reported-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180306024328.19195-1-famz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-03-08block: Fix qemu crash when using scsi-blockDeepa Srinivasan1-26/+25
Starting qemu with the following arguments causes qemu to segfault: ... -device lsi,id=lsi0 -drive file=iscsi:<...>,format=raw,if=none,node-name= iscsi1 -device scsi-block,bus=lsi0.0,id=<...>,drive=iscsi1 This patch fixes blk_aio_ioctl() so it does not pass stack addresses to blk_aio_ioctl_entry() which may be invoked after blk_aio_ioctl() returns. More details about the bug follow. blk_aio_ioctl() invokes blk_aio_prwv() with blk_aio_ioctl_entry as the coroutine parameter. blk_aio_prwv() ultimately calls aio_co_enter(). When blk_aio_ioctl() is executed from within a coroutine context (e.g. iscsi_bh_cb()), aio_co_enter() adds the coroutine (blk_aio_ioctl_entry) to the current coroutine's wakeup queue. blk_aio_ioctl() then returns. When blk_aio_ioctl_entry() executes later, it accesses an invalid pointer: .... BlkRwCo *rwco = &acb->rwco; rwco->ret = blk_co_ioctl(rwco->blk, rwco->offset, rwco->qiov->iov[0].iov_base); <--- qiov is invalid here ... In the case when blk_aio_ioctl() is called from a non-coroutine context, blk_aio_ioctl_entry() executes immediately. But if bdrv_co_ioctl() calls qemu_coroutine_yield(), blk_aio_ioctl() will return. When the coroutine execution is complete, control returns to blk_aio_ioctl_entry() after the call to blk_co_ioctl(). There is no invalid reference after this point, but the function is still holding on to invalid pointers. The fix is to change blk_aio_prwv() to accept a void pointer for the IO buffer rather than a QEMUIOVector. blk_aio_prwv() passes this through in BlkRwCo and the coroutine function casts it to QEMUIOVector or uses the void pointer directly. Signed-off-by: Deepa Srinivasan <deepa.srinivasan@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Mark Kanda <mark.kanda@oracle.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2018-03-08pc-bios/s390-ccw: Move string arrays from bootmap header to .c fileThomas Huth2-19/+20
bootmap.h can currently only be included once - otherwise the linker complains about multiple definitions of the "magic" strings. It's a bad style to define string arrays in header files, so let's better move these to the bootmap.c file instead where they are used. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1520317081-5341-1-git-send-email-thuth@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08s390x/sclp: clean up sclp masksClaudio Imbrenda6-27/+31
Introduce an sccb_mask_t to be used for SCLP event masks instead of just unsigned int or uint32_t. This will allow later to extend the mask with more ease. Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Message-Id: <1519407778-23095-3-git-send-email-imbrenda@linux.vnet.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08s390x/sclp: proper support of larger send and receive masksClaudio Imbrenda2-14/+75
Until 67915de9f0383ccf4a ("s390x/event-facility: variable-length event masks") we only supported sclp event masks with a size of exactly 4 bytes, even though the architecture allows the guests to set up sclp event masks from 1 to 1021 bytes in length. After that patch, the behaviour was almost compliant, but some issues were still remaining, in particular regarding the handling of selective reads and migration. When setting the sclp event mask, a mask size is also specified. Until now we only considered the size in order to decide which bits to save in the internal state. On the other hand, when a guest performs a selective read, it sends a mask, but it does not specify a size; the implied size is the size of the last mask that has been set. Specifying bits in the mask of selective read that are not available in the internal mask should return an error, and bits past the end of the mask should obviously be ignored. This can only be achieved by keeping track of the lenght of the mask. The mask length is thus now part of the internal state that needs to be migrated. This patch fixes the handling of selective reads, whose size will now match the length of the event mask, as per architecture. While the default behaviour is to be compliant with the architecture, when using older machine models the old broken behaviour is selected (allowing only masks of size exactly 4), in order to be able to migrate toward older versions. Fixes: 67915de9f0383ccf4a ("s390x/event-facility: variable-length event masks") Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Message-Id: <1519407778-23095-2-git-send-email-imbrenda@linux.vnet.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08vfio-ccw: license text should indicate GPL v2 or laterCornelia Huck1-2/+2
The license text currently specifies "any version" of the GPL. It is unlikely that GPL v1 was ever intended; change this to the standard "or any later version" text. Cc: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Cc: Xiao Feng Ren <renxiaof@linux.vnet.ibm.com> Cc: Pierre Morel <pmorel@linux.vnet.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Acked-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08s390x/sclpconsole: Remove dead code - remove exit handlersNia Alarie4-27/+0
The other event handlers (quiesce and cpu) do not define these handlers, and this one does nothing, so it can be removed. Signed-off-by: Nia Alarie <nia.alarie@gmail.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20180306100721.19419-1-nia.alarie@gmail.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08numa: we don't implement NUMA for s390xDavid Hildenbrand2-4/+6
Right now it is possible to crash QEMU for s390x by providing e.g. -numa node,nodeid=0,cpus=0-1 Problem is, that numa.c uses mc->cpu_index_to_instance_props as an indicator whether NUMA is supported by a machine type. We don't implement NUMA for s390x ("topology") yet. However we need mc->cpu_index_to_instance_props for query-cpus. So let's fix this case by also checking for mc->get_default_cpu_node_id, which will be needed by machine_set_cpu_numa_node(). qemu-system-s390x: -numa node,nodeid=0,cpus=0-1: NUMA is not supported by this machine-type While at it, make s390_cpu_index_to_props() look like on other architectures. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20180227110255.20999-1-david@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08hw/s390x: Add the possibility to specify the netboot image on the command lineThomas Huth1-1/+3
The file name of the netboot binary is currently hard-coded to "s390-netboot.img", without a possibility for the user to select an alternative firmware image here. That's unfortunate, especially since the basics are already there: The filename is a property of the s390-ipl device. So we just have to add a check whether the user already provided the property and only set the default if the string is still empty. Now it is possible to select a different firmware image with "-global s390-ipl.netboot_fw=/path/to/s390-netboot.img". Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1519731154-3127-1-git-send-email-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08target/s390x: Remove leading underscores from #definesThomas Huth3-70/+70
We should not use leading underscores followed by a capital letter in #defines since such identifiers are reserved by the C standard. For ASCE_ORIGIN, REGION_ENTRY_ORIGIN and SEGMENT_ENTRY_ORIGIN I also added parentheses around the value to silence an error message from checkpatch.pl. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1520227018-4061-1-git-send-email-thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08s390/ipl: only print boot menu error if -boot menu=on was specifiedCollin L. Walling1-4/+6
It is possible that certain QEMU configurations may not create an IPLB (such as when -kernel is provided). In this case, a misleading error message will be printed stating that the "boot menu is not supported for this device type". To amend this, only print this message iff boot menu=on was provided on the commandline. Otherwise, return silently. While we're at it, remove trailing periods from error messages. Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com> Message-Id: <1519760121-24594-1-git-send-email-walling@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08hw/s390x/ipl: Bail out if the network bootloader can not be foundThomas Huth1-2/+3
If QEMU fails to load 's390-netboot.img', the guest firmware currently loops forever and just floods the console with "Network boot device detected" messages. The code in ipl.c apparently already tried to stop the VM with vm_stop() in this case, but this is in vain since the run state is later reset due to a call to vm_start() from vl.c again. To avoid the ugly firmware loop, let's simply exit QEMU directly instead since it just does not make sense to continue if the required firmware image can not be loaded. While we're at it, also add the file name of the netboot binary to the error message, so that the user has a better hint about what is missing. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1519725913-24852-1-git-send-email-thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Farhan Ali <alifm@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2018-03-08.shippable.yml: disable powerpc-cross imageAlex Bennée1-2/+0
Something has happened to the old emdebian setup which means it no longer builds. Let's disable the shippable builds which are always failing. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2018-03-08sparc: fix leon3 casa instruction when MMU is disabledKONRAD Frederic1-0/+5
Since the commit af7a06bac7d3abb2da48ef3277d2a415772d2ae8: `casa [..](10), .., ..` (and probably others alternate space instructions) triggers a data access exception when the MMU is disabled. When we enter get_asi(...) dc->mem_idx is set to MMU_PHYS_IDX when the MMU is disabled. Just keep mem_idx unchanged in this case so we passthrough the MMU when it is disabled. Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2018-03-08hw/sparc/sun4m: Fix implicit creation of "-drive if=scsi" devicesThomas Huth1-0/+1
The global hack for creating SCSI devices has recently been removed, but this apparently broke SCSI devices on some boards that were not ready for this change yet. For the sun4m machines you now get: $ sparc-softmmu/qemu-system-sparc -boot d -cdrom x.iso qemu-system-sparc: -cdrom x.iso: machine type does not support if=scsi,bus=0,unit=2 Fix it by calling scsi_bus_legacy_handle_cmdline() after creating the corresponding SCSI controller. Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: 1454509726719e0933c800fad00d6999752688ea Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2018-03-07multiboot: fprintf(stderr...) -> error_report()Jack Schwartz1-26/+29
Change all fprintf(stderr...) calls in hw/i386/multiboot.c to call error_report() instead, including the mb_debug macro. Remove the "\n" from strings passed to all modified calls, since error_report() appends one. Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-07multiboot: Use header names when displaying fieldsJack Schwartz1-8/+8
Refer to field names when displaying fields in printf and debug statements. Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-07multiboot: Remove unused variables from multiboot.cJack Schwartz1-6/+0
Remove unused variables: mh_mode_type, mh_width, mh_height, mh_depth Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-07multiboot: bss_end_addr can be zeroJack Schwartz1-8/+10
The multiboot spec (https://www.gnu.org/software/grub/manual/multiboot/), section 3.1.3, allows for bss_end_addr to be zero. A zero bss_end_addr signifies there is no .bss section. Suggested-by: Daniel Kiper <daniel.kiper@oracle.com> Signed-off-by: Jack Schwartz <jack.schwartz@oracle.com> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-07RISC-V Build InfrastructureMichael Clark12-2/+72
This adds RISC-V into the build system enabling the following targets: - riscv32-softmmu - riscv64-softmmu - riscv32-linux-user - riscv64-linux-user This adds defaults configs for RISC-V, enables the build for the RISC-V CPU core, hardware, and Linux User Emulation. The 'qemu-binfmt-conf.sh' script is updated to add the RISC-V ELF magic. Expected checkpatch errors for consistency reasons: ERROR: line over 90 characters FILE: scripts/qemu-binfmt-conf.sh Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07SiFive Freedom U Series RISC-V MachineMichael Clark2-0/+408
This provides a RISC-V Board compatible with the the SiFive Freedom U SDK. The following machine is implemented: - 'sifive_u'; CLINT, PLIC, UART, device-tree Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07SiFive Freedom E Series RISC-V MachineMichael Clark2-0/+313
This provides a RISC-V Board compatible with the the SiFive Freedom E SDK. The following machine is implemented: - 'sifive_e'; CLINT, PLIC, UART, AON, GPIO, QSPI, PWM Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07SiFive RISC-V PRCI BlockMichael Clark2-0/+126
Simple model of the PRCI (Power, Reset, Clock, Interrupt) to emulate register reads made by the SDK BSP. Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07SiFive RISC-V UART DeviceMichael Clark2-0/+247
QEMU model of the UART on the SiFive E300 and U500 series SOCs. BBL supports the SiFive UART for early console access via the SBI (Supervisor Binary Interface) and the linux kernel SBI console. The SiFive UART implements the pre qom legacy interface consistent with the 16550a UART in 'hw/char/serial.c'. Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Stefan O'Rear <sorear2@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07RISC-V VirtIO MachineMichael Clark2-0/+494
RISC-V machine with device-tree, 16550a UART and VirtIO MMIO. The following machine is implemented: - 'virt'; CLINT, PLIC, 16550A UART, VirtIO MMIO, device-tree Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07SiFive RISC-V Test FinisherMichael Clark2-0/+135
Test finisher memory mapped device used to exit simulation. Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07RISC-V Spike MachinesMichael Clark2-0/+429
RISC-V machines compatble with Spike aka riscv-isa-sim, the RISC-V Instruction Set Simulator. The following machines are implemented: - 'spike_v1.9.1'; HTIF console, config-string, Privileged ISA Version 1.9.1 - 'spike_v1.10'; HTIF console, device-tree, Privileged ISA Version 1.10 Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07SiFive RISC-V PLIC BlockMichael Clark2-0/+590
The PLIC (Platform Level Interrupt Controller) device provides a parameterizable interrupt controller based on SiFive's PLIC specification. Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Stefan O'Rear <sorear2@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07SiFive RISC-V CLINT BlockMichael Clark2-0/+304
The CLINT (Core Local Interruptor) device provides real-time clock, timer and interprocessor interrupts based on SiFive's CLINT specification. Acked-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Stefan O'Rear <sorear2@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07RISC-V HART ArrayMichael Clark2-0/+128
Holds the state of a heterogenous array of RISC-V hardware threads. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07RISC-V HTIF ConsoleMichael Clark2-0/+319
HTIF (Host Target Interface) provides console emulation for QEMU. HTIF allows identical copies of BBL (Berkeley Boot Loader) and linux to run on both Spike and QEMU. BBL provides HTIF console access via the SBI (Supervisor Binary Interface) and the linux kernel SBI console. The HTIT chardev implements the pre qom legacy interface consistent with the 16550a UART in 'hw/char/serial.c'. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Stefan O'Rear <sorear2@gmail.com> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07Add symbol table callback interface to load_elfMichael Clark3-16/+53
The RISC-V HTIF (Host Target Interface) console device requires access to the symbol table to locate the 'tohost' and 'fromhost' symbols. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07RISC-V Linux User EmulationMichael Clark13-6/+1012
Implementation of linux user emulation for RISC-V. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07RISC-V Physical Memory ProtectionMichael Clark2-0/+444
Implements the physical memory protection extension as specified in Privileged ISA Version 1.10. PMP (Physical Memory Protection) is as-of-yet unused and needs testing. The SiFive verification team have PMP test cases that will be run. Nothing currently depends on PMP support. It would be preferable to keep the code in-tree for folk that are interested in RISC-V PMP support. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daire McNamara <daire.mcnamara@emdalo.com> Signed-off-by: Ivan Griffin <ivan.griffin@emdalo.com> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-07RISC-V TCG Code GenerationMichael Clark2-0/+2342