As we don't have a driver-specific mapping (yet) we should provide
for a detailed mapping from host_status to SCSI sense codes.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Message-Id: <20201116184041.60465-6-hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We really should make a distinction between legitimate sense codes
(ie if one is running against an emulated block device or for
pass-through sense codes), and the intermediate errors generated
during processing of the command, which really are not sense codes
but refer to some specific internal status. And this internal
state is not necessarily linux-specific, but rather can refer to
the qemu implementation itself.
So rename the linux-only SG_ERR codes to SCSI_HOST codes and make
them available generally.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Message-Id: <20201116184041.60465-5-hare@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This enables some simplification of vl.c via error_fatal, and improves
error messages. Before:
$ ./qemu-system-x86_64 -readconfig .
qemu-system-x86_64: error reading file
qemu-system-x86_64: -readconfig .: read config .: Invalid argument
$ /usr/libexec/qemu-kvm -readconfig foo
qemu-kvm: -readconfig foo: read config foo: No such file or directory
After:
$ ./qemu-system-x86_64 -readconfig .
qemu-system-x86_64: -readconfig .: Cannot read config file: Is a directory
$ ./qemu-system-x86_64 -readconfig foo
qemu-system-x86_64: -readconfig foo: Could not open 'foo': No such file or directory
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20210226170816.231173-1-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When loading the PVH start address from a 32 bit ELF note, extract
only the appropriate number of bytes.
Fixes: ab969087da ("pvh: Boot uncompressed kernel using direct boot ABI")
Signed-off-by: David Edmondson <david.edmondson@oracle.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-Id: <20210302090315.3031492-3-david.edmondson@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Because sizeof(struct elf64_note) == sizeof(struct elf32_note),
attempting to use the size of the currently defined struct elf_note as
a discriminator for whether the object being loaded is 64 bit in
load_elf() fails.
Instead, take advantage of the existing glue parameter SZ, which is
defined as 32 or 64 in the respective variants of load_elf().
Fixes: 696aa04c84 ("elf-ops.h: Add get_elf_note_type()")
Signed-off-by: David Edmondson <david.edmondson@oracle.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-Id: <20210302090315.3031492-2-david.edmondson@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
PCI_DEVICE has overwritten DeviceState::unrealize (pci_qdev_unrealize).
However, LSI53C895A, which is a subclass of PCI_DEVICE, overwrites it
again and doesn't save the parent's implementation so the PCI_DEVICE's
implementation of DeviceState::unrealize will never be called when
unrealize a LSI53C895A device. And it will lead to memory leak and
unplug failure.
For a PCI device, it's better to implement PCIDevice::exit instead of
DeviceState::unrealize. So let's change to use PCIDevice::exit.
Fixes: a8632434c7 ("lsi: implement I/O memory space for Memory Move instructions")
Cc: qemu-stable@nongnu.org
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Message-Id: <20210302133016.1221081-1-liangpeng10@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The parameters start and size are transfered from QEMU memory
emulation layer. It can promise that they are TARGET_PAGE_SIZE
aligned. However, KVM needs they are qemu_real_page_size aligned.
Though no caller breaks this aligned requirement currently, we'd
better add an explicit assert to avoid future breaking.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
Acked-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Message-Id: <20201217014941.22872-3-zhukeqian1@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When handle dirty log, we face qemu_real_host_page_size and
TARGET_PAGE_SIZE. The first one is the granule of KVM dirty
bitmap, and the second one is the granule of QEMU dirty bitmap.
As qemu_real_host_page_size >= TARGET_PAGE_SIZE (kvm_init()
enforced it), misuse TARGET_PAGE_SIZE to init kvmslot dirty_bmap
may waste memory. For example, when qemu_real_host_page_size is
64K and TARGET_PAGE_SIZE is 4K, it wastes 93.75% (15/16) memory.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20201217014941.22872-2-zhukeqian1@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit v5.2.0-190-g0546c0609c ("vl: split various early command line
options to a separate function") moved the trace backend init code to
the qemu_process_early_options(). Which is now being called before
os_daemonize() via qemu_maybe_daemonize().
Turns out that this change of order causes a problem when executing
QEMU in daemon mode and with CONFIG_TRACE_SIMPLE. The trace thread
is now being created by the parent, and the parent is left waiting for
a trace file flush that was registered via st_init(). The result is
that the parent process never exits.
To reproduce, fire up a QEMU process with -daemonize and with
CONFIG_TRACE_SIMPLE enabled. Two QEMU process will be left in the
host:
$ sudo ./x86_64-softmmu/qemu-system-x86_64 -S -no-user-config -nodefaults \
-nographic -machine none,accel=kvm:tcg -daemonize
$ ps axf | grep qemu
529710 pts/3 S+ 0:00 | \_ grep --color=auto qemu
529697 ? Ssl 0:00 \_ ./x86_64-softmmu/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -daemonize
529699 ? Sl 0:00 \_ ./x86_64-softmmu/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -daemonize
The parent thread is hang in flush_trace_file:
$ sudo gdb ./x86_64-softmmu/qemu-system-x86_64 529697
(..)
(gdb) bt
#0 0x00007f9dac6a137d in syscall () at /lib64/libc.so.6
#1 0x00007f9dacc3c4f3 in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x0000555d12f952da in flush_trace_file (wait=true) at ../trace/simple.c:140
#3 0x0000555d12f95b4c in st_flush_trace_buffer () at ../trace/simple.c:383
#4 0x00007f9dac5e43a7 in __run_exit_handlers () at /lib64/libc.so.6
#5 0x00007f9dac5e4550 in on_exit () at /lib64/libc.so.6
#6 0x0000555d12d454de in os_daemonize () at ../os-posix.c:255
#7 0x0000555d12d0bd5c in qemu_maybe_daemonize (pid_file=0x0) at ../softmmu/vl.c:2408
#8 0x0000555d12d0e566 in qemu_init (argc=8, argv=0x7fffc594d9b8, envp=0x7fffc594da00) at ../softmmu/vl.c:3459
#9 0x0000555d128edac1 in main (argc=8, argv=0x7fffc594d9b8, envp=0x7fffc594da00) at ../softmmu/main.c:49
(gdb)
Aside from the 'zombie' process in the host, this is directly impacting
Libvirt. Libvirt waits for the parent process to exit to be sure that the
QMP monitor is available in the daemonized process to fetch QEMU
capabilities, and as is now Libvirt hangs at daemon start waiting
for the parent thread to exit.
The fix is simple: just move the trace backend related code back to
be executed after daemonizing.
Fixes: 0546c0609c
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20210105181437.538366-2-danielhb413@gmail.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Most code paths for creating a user creatable object go through
QemuOpts, which ensures that the provided 'id' option is actually a
valid identifier.
However, there are some code paths that don't go through QemuOpts:
qemu-storage-daemon --object (since commit 8db1efd3) and QMP object-add
(since it was first introduced in commit cff8b2c6). We need to have the
same validity check for those, too.
This adds the check and makes it print the same error message as
QemuOpts on failure.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20210302171623.49709-1-kwolf@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The "delay" option was introduced as a way to enable Nagle's algorithm
with ",nodelay". Since the short form for boolean options has now been
deprecated, introduce a more properly named "nodelay" option. The "delay"
option remains as an undocumented option.
"delay" and "nodelay" are mutually exclusive. Because the check is
done at consumption time, the code also rejects them if one of the
two is specified via -set.
Based-on: <20210226080526.651705-1-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The current GLib version implements the DllMain function. DllMain is also
present in the provider.cpp code. So in the case of static linking, the
DllMain redefinition error occurs. For now, just switch to dynamic linking
and revert this patch when the issue will be solved.
See Glib issue for more details https://gitlab.gnome.org/GNOME/glib/-/issues/692
Signed-off-by: Kostiantyn Kostiuk <konstantin@daynix.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The userspace local APIC is basically untested and does not support many
features such as TSC deadline timer, x2APIC or PV spinlocks. On the
other hand, the PIT and IOAPIC are okay as they are not tied to
the processor and are tested with -M kernel-irqchip=split.
Therefore, deprecate the local APIC and, with it, limit
-M kernel-irqchip=off to the ISA PC machine type, which does not
have a local APIC at all.
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If kvm_arch_remove_sw_breakpoint finds that a software breakpoint does not
have an INT3 instruction, it fails. This can happen if one sets a
software breakpoint in a kernel module and then reloads it. gdb then
thinks the breakpoint cannot be deleted and there is no way to add it
back.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
For a long time now the UI layer has guaranteed that the console
surface is always 32 bits per pixel RGB. Remove the legacy dead
code from the tc6393xb display device which was handling the
possibility that the console surface was some other format.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210215103215.4944-3-peter.maydell@linaro.org
For a long time now the UI layer has guaranteed that the console
surface is always 32 bits per pixel RGB. Remove the legacy dead
code from the milkymist display device which was handling the
possibility that the console surface was some other format.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210215103215.4944-2-peter.maydell@linaro.org
We will move this code in the next commit. Clean it up
first to avoid checkpatch.pl errors.
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20210221222617.2579610-3-f4bug@amsat.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
IDAU is specific to M-profile. KVM only supports A-profile.
Restrict this interface to TCG, as it is pointless (and
confusing) on a KVM-only build.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20210221222617.2579610-2-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Section D6.7 of the ARM ARM states:
For the purpose of determining Tag Check Fault handling, unprivileged
load and store instructions are treated as if executed at EL0 when
executed at either:
- EL1, when the Effective value of PSTATE.UAO is 0.
- EL2, when both the Effective value of HCR_EL2.{E2H, TGE} is {1, 1}
and the Effective value of PSTATE.UAO is 0.
ARM has confirmed a defect in the pseudocode function
AArch64.TagCheckFault that makes it inconsistent with the above
wording. The remedy is to adjust references to PSTATE.EL in that
function to instead refer to AArch64.AccessUsesEL(acctype), so
that unprivileged instructions use SCTLR_EL1.TCF0 and TFSRE0_EL1.
The exception type for synchronous tag check faults remains unchanged.
This patch implements the described change by partially reverting
commits 50244cc76a and cc97b0019b.
Signed-off-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210219201820.2672077-1-pcc@google.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
At the moment the following QEMU command line triggers an assertion
failure On xlnx-versal SOC:
qemu-system-aarch64 \
-machine xlnx-versal-virt -nographic -smp 2 -m 128 \
-fsdev local,id=shareid,path=${HOME}/work,security_model=none \
-device virtio-9p-device,fsdev=shareid,mount_tag=share \
-fsdev local,id=shareid1,path=${HOME}/Music,security_model=none \
-device virtio-9p-device,fsdev=shareid1,mount_tag=share1
qemu-system-aarch64: ../migration/savevm.c:860:
vmstate_register_with_alias_id:
Assertion `!se->compat || se->instance_id == 0' failed.
This problem was fixed on arm virt platform in commit f58b39d2d5
("virtio-mmio: format transport base address in BusClass.get_dev_path")
It works perfectly on arm virt platform. but there is still there on
xlnx-versal SOC.
The main difference between arm virt and xlnx-versal is they use
different way to create virtio-mmio qdev. on arm virt, it calls
sysbus_create_simple("virtio-mmio", base, pic[irq]); which will call
sysbus_mmio_map internally and assign base address to subsys device
mmio correctly. but xlnx-versal's implements won't do this.
However, xlnx-versal can't switch to sysbus_create_simple() to create
virtio-mmio device. It's because xlnx-versal's cpu use
VersalVirt.soc.fpd.apu.mr as it's memory. which is subregion of
system_memory. sysbus_create_simple will add virtio to system_memory,
which can't be accessed by cpu.
Besides, xlnx-versal can't add sysbus_mmio_map api call too, because
this will add memory region to system_memory, and it can't be added
to VersalVirt.soc.fpd.apu.mr again.
We can solve this by assign correct base address offset on dev_path.
This path was test on aarch64 virt & xlnx-versal platform.
Signed-off-by: schspa <schspa@gmail.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The STATUS register will be reset to IDLE in
cnpcm7xx_smbus_enter_reset(), no need to preset
it in instance_init().
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Hao Wu <wuhaotsh@google.com>
Message-id: 20210228224813.312532-1-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Always perform one call instead of two for 16-byte operands.
Use byte loads/stores directly into the vector register file
instead of extractions and deposits to a 64-bit local variable.
In order to easily receive pointers into the vector register file,
convert the helper to the gvec out-of-line signature. Move the
helper into vec_helper.c, where it can make use of H1 and clear_tail.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20210224230532.276878-1-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We hint the 'has_rpu' property is no longer required since commit
6908ec448b ("xlnx-zynqmp: Properly support the smp command line
option") which was released in QEMU v2.11.0.
Beside, this device is marked 'user_creatable = false', so the
only thing that could be setting the property is the board code
that creates the device.
Since the property is not user-facing, we can remove it without
going through the deprecation process.
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20210219144350.1979905-1-f4bug@amsat.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This is a 10/100 ethernet device that has several features.
Only the ones needed by the Linux driver have been implemented.
See npcm7xx_emc.c for a list of unimplemented features.
Reviewed-by: Hao Wu <wuhaotsh@google.com>
Reviewed-by: Avi Fishman <avi.fishman@nuvoton.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Doug Evans <dje@google.com>
Message-id: 20210218212453.831406-3-dje@google.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This is a 10/100 ethernet device that has several features.
Only the ones needed by the Linux driver have been implemented.
See npcm7xx_emc.c for a list of unimplemented features.
Reviewed-by: Hao Wu <wuhaotsh@google.com>
Reviewed-by: Avi Fishman <avi.fishman@nuvoton.com>
Signed-off-by: Doug Evans <dje@google.com>
Message-id: 20210218212453.831406-2-dje@google.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Set ID_AA64PFR1_EL1.SSBS to 2 and ID_PFR2.SSBS to 1.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210216224543.16142-3-rebecca@nuviainc.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add support for FEAT_SSBS. SSBS (Speculative Store Bypass Safe) is an
optional feature in ARMv8.0, and mandatory in ARMv8.5.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210216224543.16142-2-rebecca@nuviainc.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Let add 'max' cpu while work goes on adding newer CPU types than
Cortex-A72. This allows us to check SVE etc support.
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20210216150122.3830863-3-marcin.juszkiewicz@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commit 9d55380b5a "qapi: Remove null from schema language" (v4.2.0)
neglected to update two error messages. Do that now.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20210224101442.1837475-1-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
We removed the QMP loop in user-mode builds in commit 1935e0e4e0
("qapi/meson: Remove QMP from user-mode emulation"), now commands
and events code is unreachable.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210224171642.3242293-1-philmd@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
I found another spot that can benefit from using our macros instead of
open-coding qapi list creation.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210205171634.1491258-1-eblake@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Setting errp = NULL is wrong: the automatic error propagation still
propagates the dangling pointer _auto_errp_prop.local_err. We need to
set *errp = NULL to clear the dangling pointer.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20210125132635.1253219-1-armbru@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This PR is a collection of RISC-V patches:
- Improvements to SiFive U OTP
- Upgrade OpenSBI to v0.9
- Support the QMP dump-guest-memory
- Add support for the SiFive SPI controller (sifive_u)
- Initial RISC-V system documentation
- A fix for the Goldfish RTC
- MAINTAINERS updates
- Support for high PCIe memory in the virt machine
-----BEGIN PGP SIGNATURE-----
iQEyBAABCAAdFiEE9sSsRtSTSGjTuM6PIeENKd+XcFQFAmBA8k8ACgkQIeENKd+X
cFRRMgf41R7Zn1ZSB9GHL3WgLDTPqpT4FAMpTnYRD7wPdspawl1SsHWBgaLNmJWk
dwSLhvHMM44pOVCQRqdkiRrp5t5fDEm6gdRKyNn5uzWFMn7ibYIjmg7OE+79onbN
VES4yTJwuskD/7JRNcrW6RytKRgzKs2au8NxxgtgXprSF0nM9wCu70z4T9XkLfjQ
cpJUUaUCw628uUic/nObTxMnaiEmq/C0qU9SRRKPYVRp7jceCsHMVRazqOgdM6uf
foNHi/uCNKy6I841+D8Po7h57s51LtT78JDRRVRPfWY+SRQyC5l8Eq3UtRPyg39p
7hhkiAKhG4rs8iCXKvMvTz0S//Cx
=BVLq
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/alistair/tags/pull-riscv-to-apply-20210304' into staging
RISC-V PR for 6.0
This PR is a collection of RISC-V patches:
- Improvements to SiFive U OTP
- Upgrade OpenSBI to v0.9
- Support the QMP dump-guest-memory
- Add support for the SiFive SPI controller (sifive_u)
- Initial RISC-V system documentation
- A fix for the Goldfish RTC
- MAINTAINERS updates
- Support for high PCIe memory in the virt machine
# gpg: Signature made Thu 04 Mar 2021 14:44:31 GMT
# gpg: using RSA key F6C4AC46D4934868D3B8CE8F21E10D29DF977054
# gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [full]
# Primary key fingerprint: F6C4 AC46 D493 4868 D3B8 CE8F 21E1 0D29 DF97 7054
* remotes/alistair/tags/pull-riscv-to-apply-20210304:
hw/riscv: virt: Map high mmio for PCIe
hw/riscv: virt: Limit RAM size in a 32-bit system
hw/riscv: virt: Drop the 'link_up' parameter of gpex_pcie_init()
hw/riscv: Drop 'struct MemmapEntry'
MAINTAINERS: Add a SiFive machine section
goldfish_rtc: re-arm the alarm after migration
docs/system: riscv: Add documentation for sifive_u machine
docs/system: Add RISC-V documentation
docs/system: Sort targets in alphabetical order
hw/riscv: sifive_u: Change SIFIVE_U_GEM_IRQ to decimal value
hw/riscv: sifive_u: Add QSPI2 controller and connect an SD card
hw/riscv: sifive_u: Add QSPI0 controller and connect a flash
hw/ssi: Add SiFive SPI controller support
hw/block: m25p80: Add various ISSI flash information
hw/block: m25p80: Add ISSI SPI flash support
target-riscv: support QMP dump-guest-memory
roms/opensbi: Upgrade from v0.8 to v0.9
hw/misc: sifive_u_otp: Use error_report() when block operation fails
target/riscv: Declare csr_ops[] with a known size
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Some peripherals require 64-bit PCI address, so let's map the high
mmio space for PCIe.
For RV32, the address is hardcoded to below 4 GiB from the highest
accessible physical address. For RV64, the base address depends on
top of RAM and is aligned to its size which is using 16 GiB for now.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20210220144807.819-5-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
RV32 supports 34-bit physical address hence the maximum RAM size
should be limited. Limit the RAM size to 10 GiB, which leaves
some room for PCIe high mmio space.
For 32-bit host, this is not needed as machine->ram_size cannot
represent a RAM size that big. Use a #if size test to only do
the size limitation for the 64-bit host.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20210220144807.819-4-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
`link_up` is never used in gpex_pcie_init(). Drop it.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20210220144807.819-3-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
There is already a MemMapEntry type defined in hwaddr.h. Let's drop
the RISC-V defined `struct MemmapEntry` and use the existing one.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20210220144807.819-2-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
After a migration the clock offset is updated, but we also
need to re-arm the alarm if needed.
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20201220112615.933036-7-laurent@vivier.eu
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
This adds detailed documentation for RISC-V `sifive_u` machine,
including the following information:
- Supported devices
- Hardware configuration information
- Boot options
- Machine-specific options
- Running Linux kernel
- Running VxWorks kernel
- Running U-Boot, and with an alternate configuration
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com>
Message-id: 20210126060007.12904-10-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Add RISC-V system emulator documentation for generic information.
`Board-specific documentation` and `RISC-V CPU features` are only
a placeholder and will be added in the future.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20210126060007.12904-9-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20210126060007.12904-8-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
All other peripherals' IRQs are in the format of decimal value.
Change SIFIVE_U_GEM_IRQ to be consistent.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20210126060007.12904-7-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
This adds the QSPI2 controller to the SoC, and connects an SD
card to it. The generation of corresponding device tree source
fragment is also added.
Specify machine property `msel` to 11 to boot the same upstream
U-Boot SPL and payload image for the SiFive HiFive Unleashed board.
Note subsequent payload is stored in the SD card image.
$ qemu-system-riscv64 -nographic -M sifive_u,msel=11 -smp 5 -m 8G \
-bios u-boot-spl.bin -drive file=sdcard.img,if=sd
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20210126060007.12904-6-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
This adds the QSPI0 controller to the SoC, and connects an ISSI
25WP256 flash to it. The generation of corresponding device tree
source fragment is also added.
Since the direct memory-mapped mode is not supported by the SiFive
SPI model, the <reg> property does not populate the second group
which represents the memory mapped address of the SPI flash.
With this commit, upstream U-Boot for the SiFive HiFive Unleashed
board can boot on QEMU 'sifive_u' out of the box. This allows users
to develop and test the recommended RISC-V boot flow with a real
world use case: ZSBL (in QEMU) loads U-Boot SPL from SPI flash to
L2LIM, then U-Boot SPL loads the payload from SPI flash that is
combined with OpenSBI fw_dynamic firmware and U-Boot proper.
Specify machine property `msel` to 6 to allow booting from the SPI
flash. U-Boot spl is directly loaded via `-bios`, and subsequent
payload is stored in the SPI flash image. Example command line:
$ qemu-system-riscv64 -nographic -M sifive_u,msel=6 -smp 5 -m 8G \
-bios u-boot-spl.bin -drive file=spi-nor.img,if=mtd
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20210126060007.12904-5-bmeng.cn@gmail.com
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>