Just found while investigating
https://bugzilla.redhat.com/show_bug.cgi?id=1707118
Found PCIe extended config space filled with random crap due to
allocation being too small (conventional pci config space only).
PCI(e) config space is guest writable. Writes are limited by
write mask (which pro
Set QEMU_PCI_CAP_EXPRESS unconditionally in init(), then clear it in
realize() in case the device is not connected to a PCIe bus.
This makes sure the pci config space allocation is big enough, so
accessing the PCIe extended config space doesn't overflow the pci
config space buffer.
Signed-off-by:
On 8/12/2019 1:13 PM, Daniel Black wrote:
Tao Xu, Liu Jingqi,
Thanks for doing these updates.
On Fri, 9 Aug 2019 14:57:29 +0800
Tao wrote:
From: Liu Jingqi
Add -numa hmat-lb option to provide System Locality Latency and
Bandwidth Information. These memory attributes help to build
System
On 8/8/19 3:55 PM, Stefan Hajnoczi wrote:
> On Wed, Aug 07, 2019 at 12:44:39PM +0530, Balamuruhan S wrote:
>> This is a proposal to extend mmio callbacks in Qemu with scripting interface
>> that is prototyped with python in this implementation. It gives ability to
>> feed runtime data through ca
Currently we basically print IO address twice, fix this.
Fixes: 7e472264e9e2 ("PPC: spapr: iommu: rework traces")
Signed-off-by: Alexey Kardashevskiy
---
hw/ppc/spapr_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c
index bd3
sysemu/sysemu.h is a rather unfocused dumping ground for stuff related
to the system-emulator. Evidence:
* It's included widely: in my "build everything" tree, changing
sysemu/sysemu.h still triggers a recompile of some 1100 out of 6600
objects (not counting tests and objects that don't depen
We have quite a few "touch this, recompile the world" headers. My
"build everything" tree has some 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h). Touching any of 54
headers triggers a recompile of more than half of them.
This series reduces them to 46.
Six of t
Back in 2016, we discussed[1] rules for headers, and these were
generally liked:
1. Have a carefully curated header that's included everywhere first. We
got that already thanks to Peter: osdep.h.
2. Headers should normally include everything they need beyond osdep.h.
If exceptions are need
docs/devel/tracing.txt explains "since many source files include
trace.h, [the generated trace.h use] a minimum of types and other
header files included to keep the namespace clean and compile times
and dependencies down."
Commit 4815185902 "trace: Add per-vCPU tracing states for events with
the '
In my "build everything" tree, changing hw/irq.h triggers a recompile
of some 5400 out of 6600 objects (not counting tests and objects that
don't depend on qemu/osdep.h).
hw/hw.h supposedly includes it for convenience. Several other headers
include it just to get qemu_irq and.or qemu_irq_handler.
In my "build everything" tree, changing sysemu/reset.h triggers a
recompile of some 2600 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h).
The main culprit is hw/hw.h, which supposedly includes it for
convenience.
Include sysemu/reset.h only where it's needed
In my "build everything" tree, changing hw/hw.h triggers a recompile
of some 2600 out of 6600 objects (not counting tests and objects that
don't depend on qemu/osdep.h).
The previous commits have left only the declaration of hw_error() in
hw/hw.h. This permits dropping most of its inclusions. To
In my "build everything" tree, changing qemu/main-loop.h triggers a
recompile of some 5600 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h). It includes block/aio.h,
which in turn includes qemu/event_notifier.h, qemu/notify.h,
qemu/processor.h, qemu/qsp.h, qem
hw/boards.h pulls in almost 60 headers. The less we include it into
headers, the better. As a first step, drop superfluous inclusions,
and downgrade some more to what's actually needed. Gets rid of just
one inclusion into a header.
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Signed-off-by: Marku
sysemu/numa.h includes hw/boards.h just for the CPUArchId typedef, at
the cost of pulling in more than two dozen extra headers indirectly.
I could move the typedef from hw/boards.h to qemu/typedefs.h. But
it's used in just two headers: boards.h and numa.h.
I could move it to another header both
In my "build everything" tree, changing sysemu/sysemu.h triggers a
recompile of some 5400 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h).
hw/qdev-core.h includes sysemu/sysemu.h since recent commit e965ffa70a
"qdev: add qdev_add_vm_change_state_handler()".
In my "build everything" tree, changing sysemu/sysemu.h triggers a
recompile of some 5400 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h).
Almost a third of its inclusions are actually superfluous. Delete
them. Downgrade two more to qapi/qapi-types-run-stat
Drop unnecessary inclusions from headers. Downgrade a few more to
exec/hwaddr.h.
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
hw/audio/lm4549.h | 1 +
hw/net/can/can_sja1000.h| 1 +
hw/xtensa/xtensa_me
In my "build everything" tree, changing sysemu/sysemu.h triggers a
recompile of some 1800 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h, down from 5400 due to the
previous commit).
Several headers include sysemu/sysemu.h just to get typedef
VMChangeStateEntr
We declare incomplete struct VMStateDescription in a couple of places
so we don't have to include migration/vmstate.h for the typedef.
That's fine with me. However, the next commit will drop
migration/vmstate.h from a massive number of compiles. Move the
typedef to qemu/typedefs.h now, so I don't
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
include/exec/cpu-defs.h | 1 -
include/hw/xen/xen_common.h | 1 -
include/net/can_emu.h | 1 +
include/net/filter.h| 1 +
include/qemu/range.h| 2 --
include/qom/
Commit e35704ba9c "numa: Move NUMA declarations from sysemu.h to
numa.h" left a few NUMA-related macros behind. Move them now.
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Eduardo Habkost
---
include/sysemu/hostme
In my "build everything" tree, changing migration/qemu-file-types.h
triggers a recompile of some 2600 out of 6600 objects (not counting
tests and objects that don't depend on qemu/osdep.h).
The culprit is again hw/hw.h, which supposedly includes it for
convenience.
Include migration/qemu-file-typ
Move the HostMemoryBackend typedef from sysemu/hostmem.h to
qemu/typedefs.h. This renders a few inclusions of sysemu/hostmem.h
superfluous; drop them.
Cc: Eduardo Habkost
Cc: Igor Mammedov
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Eduardo Habkost
Revie
hw/hw.h used to include headers hardware emulation "usually" needs.
The previous commits removed all but one of them, to good effect.
Only qom/object.h is left. Remove that one, too.
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
inc
migration/qemu-file.h neglects to include it even though it needs
ram_addr_t. Fix that. Drop a few superfluous inclusions elsewhere.
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
include/hw/hw.h | 1 -
include/hw/pp
When commit 5f7d05ecfda added QLIST_INSERT_HEAD_RCU() to qemu/queue.h,
it had to include qemu/atomic.h. Commit 341774fe6cc removed
QLIST_INSERT_HEAD_RCU() again, but neglected to remove the #include.
Do that now.
Signed-off-by: Markus Armbruster
Reviewed-by: Thomas Huth
Reviewed-by: Philippe Ma
Some of the generated qapi-types-MODULE.h are included all over the
place. Changing a QAPI type can trigger massive recompiling. Top
scorers recompile more than 1000 out of some 6600 objects (not
counting tests and objects that don't depend on qemu/osdep.h):
6300 qapi/qapi-builtin-types.h
According to hw/ide/internal's file comment, only files in hw/ide/ are
supposed to include it. Drag reality slightly closer to supposition.
Three includes outside hw/ide remain: hw/arm/sbsa-ref.c,
include/hw/ide/pci.h, and include/hw/misc/macio/macio.h. Turns out
board code needs ide-internal.h
TYPE_IOMMU_MEMORY_REGION is a direct subtype of TYPE_MEMORY_REGION.
Its instance struct is IOMMUMemoryRegion, and its first member is a
MemoryRegion. Correct. Its class struct is IOMMUMemoryRegionClass,
and its first member is a DeviceClass. Wrong. Messed up when commit
1221a474676 introduced t
In my "build everything" tree, changing a type in qapi/common.json
triggers a recompile of some 3600 out of 6600 objects (not counting
tests and objects that don't depend on qemu/osdep.h).
One common dependency is QapiErrorClass: it's used only in in
qapi/error.h, which uses nothing else, and is w
While there, drop the obsolete file comment.
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
include/qemu/typedefs.h | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/include/qemu/typedefs.h b/include/qem
hw/tpm/trace-events uses TARGET_FMT_plx formats with uint64_t
arguments. That's wrong, TARGET_FMT_plx takes hwaddr. Since hwaddr
happens to be uint64_t, it works anyway. Messed up in commit
ec427498da5, v2.12.0. Clean up by replacing TARGET_FMT_plx with its
macro expansion.
scripts/tracetool/f
Tao Xu, Liu Jingqi,
Thanks for doing these updates.
On Fri, 9 Aug 2019 14:57:29 +0800
Tao wrote:
> From: Liu Jingqi
>
> Add -numa hmat-lb option to provide System Locality Latency and
> Bandwidth Information. These memory attributes help to build
> System Locality Latency and Bandwidth In
On 8/9/19 10:19 AM, David Gibson wrote:
> On Wed, Aug 07, 2019 at 10:15:48AM +0200, Cédric Le Goater wrote:
>> On 07/08/2019 09:14, Balamuruhan S wrote:
>>> Hi All,
>>>
>>> This is a proposal to extend mmio callbacks in Qemu with scripting interface
>>> that is prototyped with python in this implem
On 8/9/19 2:16 PM, Stefan Hajnoczi wrote:
> On Thu, Aug 08, 2019 at 11:53:07AM +0100, Daniel P. Berrangé wrote:
>> On Thu, Aug 08, 2019 at 11:10:13AM +0100, Stefan Hajnoczi wrote:
>>> On Wed, Aug 07, 2019 at 12:20:47PM +0200, Philippe Mathieu-Daudé wrote:
> +void python_args_clean(char *args
On 8/8/19 6:15 PM, Philippe Mathieu-Daudé wrote:
> On 8/8/19 12:49 PM, Daniel P. Berrangé wrote:
>> On Wed, Aug 07, 2019 at 12:44:40PM +0530, Balamuruhan S wrote:
>>> Adds scripting interface with python library to call functions in
>>> python modules from Qemu that can be used to feed input extern
On Fri, Aug 09, 2019 at 10:12:14AM +0100, Daniel P. Berrangé wrote:
>On Fri, Aug 09, 2019 at 08:06:09AM +0800, Wei Yang wrote:
>> On Thu, Aug 08, 2019 at 10:22:13AM +0100, Daniel P. Berrangé wrote:
>> >On Thu, Aug 08, 2019 at 04:46:53PM +0800, Wei Yang wrote:
>> >> On Thu, Aug 08, 2019 at 09:02:29A
Fixes: a38127414bd007c5b6ae64c664d9e8839393277e
Signed-off-by: BALATON Zoltan
---
hw/display/ati.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/display/ati.c b/hw/display/ati.c
index 699f38223b..b849f5d510 100644
--- a/hw/display/ati.c
+++ b/hw/display/ati.c
@@ -207,7 +2
The crtc_offset is not needed, cur_offset is relative to the start of
vram not the start of displayed area. This fixes broken pointer image
with MacOS that uses non-0 crtc_offset.
Signed-off-by: BALATON Zoltan
---
hw/display/ati.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
di
Add names for AMCGPIO regs to make it easier to identify these in
trace output. This is where rage128p has the DDC from the DVI port
among others but because we don't implement the flat panel controller
we don't want to connect an EDID here to make sure drivers use the VGA
output instead. But since
MacOS uses non-0 offset so it needs this and the resulting
vbe_start_addr seems correct but picture is still broken with OpenBIOS
after FCode runs but that maybe due to firmware problems now. After
boot, picture is now correct.
It also occured to me that these CRTC regs are also present in VGA so
Some drivers (e.g. Linux radeon drm and MacOS) access these to find
apertures to access card. Try to implement these but not sure these
are correct yet.
Signed-off-by: BALATON Zoltan
---
hw/display/ati.c | 15 +++
hw/display/ati_dbg.c | 5 +
hw/display/ati_regs.h | 5
Hello,
This is the latest version of all outstanding ati-vga patches
collected in one series. Some of these or previous versions of them
were sent individually before but these are now superceding all
previous patches that are not yet in master and this series is all
that should be needed.
This s
Also update bitbang_i2c state when output bits are changed while
enable bits are set. This fixes EDID access by the ATI FCode ROM.
Signed-off-by: BALATON Zoltan
---
hw/display/ati.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/display/ati.c b/hw/display/ati.
Set frame buffer endianness according to requested endianness for
frame buffer apertures. We set frame buffer to big endian if any of
the two apertures are set to big endian. Using different endianness
for the two apertures is not implemented. This fixes inverted colors
with MacOS and Xorg frame bu
In some cases buf_align or request_alignment cannot be detected:
- With Gluster, buf_align cannot be detected since the actual I/O is
done on Gluster server, and qemu buffer alignment does not matter.
- With local XFS filesystem, buf_align cannot be detected if reading
from unallocated area.
This was broken by the cherry-pick in 41dd30f. Fix by handling errors
as in the rest of the function: "goto out" instead of "return rc".
Signed-off-by: Stephen Kitt
---
hw/rdma/vmw/pvrdma_cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/rdma/vmw/pvrdma_cmd.c b/hw/rdma
On Sun, Aug 11, 2019 at 1:13 AM Bin Meng wrote:
>
> The Linux kernel SiFive UART driver expects an aliases node to be
> present in the device tree, from which the driver extracts the port
> number from "serial#" in the aliases node.
>
> Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Ali
On Sun, Aug 11, 2019 at 1:18 AM Bin Meng wrote:
>
> This removes "reg-names" and "riscv,max-priority" properties of the
> PLIC node from device tree.
>
> Signed-off-by: Bin Meng
> Reviewed-by: Jonathan Behrens
Reviewed-by: Alistair Francis
Alistair
> ---
>
> Changes in v3: None
> Changes in
On Sun, Aug 11, 2019 at 1:14 AM Bin Meng wrote:
>
> There is no need to return fdt at the end of create_fdt() because
> it's already saved in s->fdt. Other machines (sifive_u, spike)
> don't do it neither.
>
> Signed-off-by: Bin Meng
> Reviewed-by: Chih-Min Chao
> Reviewed-by: Philippe Mathieu-D
On Sun, Aug 11, 2019 at 1:17 AM Bin Meng wrote:
>
> The loading of initramfs is currently not supported on 'sifive_u'.
> Add the support to make '-initrd' command line parameter useful.
>
> Signed-off-by: Bin Meng
> Reviewed-by: Chih-Min Chao
Reviewed-by: Alistair Francis
Alistair
> ---
>
>
On Sun, Aug 11, 2019 at 1:15 AM Bin Meng wrote:
>
> At present the GEM support in sifive_u machine is seriously broken.
>
> - The GEM block register base was set to a weird number (0x100900FC),
> which for no way could work with the cadence_gem model in QEMU.
> - The generated DT node for GEM ha
On Sun, Aug 11, 2019 at 1:13 AM Bin Meng wrote:
>
> This adds an OTP memory with a given serial number to the sifive_u
> machine. With such support, the upstream U-Boot for sifive_fu540
> boots out of the box on the sifive_u machine.
>
> Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Al
On Sun, Aug 11, 2019 at 1:12 AM Bin Meng wrote:
>
> This adds a simple PRCI model for FU540 (sifive_u). It has different
> register layout from the existing PRCI model for FE310 (sifive_e).
>
> Signed-off-by: Bin Meng
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> hw/riscv/Makefile.objs
On Sun, Aug 11, 2019 at 1:11 AM Bin Meng wrote:
>
> Currently the PRCI register block size is set to 0x8000, but in fact
> 0x1000 is enough, which is also what the manual says.
>
> Signed-off-by: Bin Meng
> Reviewed-by: Chih-Min Chao
Reviewed-by: Alistair Francis
Alistair
> ---
>
> Changes i
On Sun, Aug 11, 2019 at 1:00 AM Bin Meng wrote:
>
> Hi Alistair,
>
> On Sat, Aug 10, 2019 at 9:51 AM Alistair Francis wrote:
> >
> > On Wed, Aug 7, 2019 at 12:49 AM Bin Meng wrote:
> > >
> > > Current SiFive PRCI model only works with sifive_e machine, as it
> > > only emulates registers or PRCI
On Sun, Aug 11, 2019 at 1:08 AM Bin Meng wrote:
>
> It is not useful if we only have one management CPU.
>
> Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Alistair
>
> ---
>
> Changes in v3:
> - use management cpu count + 1 for the min_cpus
>
> Changes in v2:
> - update the file heade
On Sun, Aug 11, 2019 at 1:10 AM Bin Meng wrote:
>
> The FU540-C000 includes a 64-bit E51 RISC-V core and four 64-bit U54
> RISC-V cores. Currently the sifive_u machine only populates 4 U54
> cores. Update the max cpu number to 5 to reflect the real hardware,
> and pass "cpu-type" to populate heter
On Sun, Aug 11, 2019 at 1:07 AM Bin Meng wrote:
>
> Currently riscv_harts_realize() creates all harts based on the
> same cpu type given in the hart array property. With current
> implementation it can only create symmetric harts. Exact the
> hart realize to a separate routine in preparation for s
On Sat, Aug 10, 2019 at 6:55 AM LIU ZhiWei wrote:
>
>
> On 8/9/19 6:54 PM, Alistair Francis wrote:
>
> On Thu, Aug 8, 2019 at 2:52 AM liuzhiwei wrote:
>
> Hi all,
>
> My workmate and I have been working on Vector & Dsp extension, and
> I'd like to share develop status with folks.
>
> Cool!
On 8/11/19 1:06 AM, Bin Meng wrote:
> +/* heterogeneous harts */
> +while (tmp_type) {
> +if (n >= s->num_harts) {
> +break;
> +}
> +riscv_hart_realize(s, n++, tmp_type, errp);
> +last_type = tmp_type;
> +tm
On 8/10/19 7:35 PM, Richard Henderson wrote:
> On 8/9/19 9:12 PM, Jan Bobek wrote:
>> This is a v2 of the patch series posted in [1]. Patches 1-9 are just
>> cleanups; patches 10-39 are something actually interesting. Compared
>> to v1, I started using preprocessor more extensively to generate
>> r
On Sun, Aug 11, 2019 at 4:07 PM Bin Meng wrote:
>
> As of today, the QEMU 'sifive_u' machine is a special target that does
> not boot the upstream OpenSBI/U-Boot firmware images built for the real
> SiFive HiFive Unleashed board. Hence OpenSBI supports a special platform
> "qemu/sifive_u". For U-B
This updates model and compatible strings to use the same strings
as used in the Linux kernel device tree (hifive-unleashed-a00.dts).
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v3: None
Changes in v2: None
hw/riscv/sifive_u.c | 5 +++--
1 file changed, 3 insertions(
This removes "reg-names" and "riscv,max-priority" properties of the
PLIC node from device tree.
Signed-off-by: Bin Meng
Reviewed-by: Jonathan Behrens
---
Changes in v3: None
Changes in v2:
- keep the PLIC compatible string unchanged as OpenSBI uses that
for DT fix up
hw/riscv/sifive_u.c |
The loading of initramfs is currently not supported on 'sifive_u'.
Add the support to make '-initrd' command line parameter useful.
Signed-off-by: Bin Meng
Reviewed-by: Chih-Min Chao
---
Changes in v3: None
Changes in v2: None
hw/riscv/sifive_u.c | 13 -
1 file changed, 12 inserti
At present the GEM support in sifive_u machine is seriously broken.
- The GEM block register base was set to a weird number (0x100900FC),
which for no way could work with the cadence_gem model in QEMU.
- The generated DT node for GEM has a "clocks-names" which is an
invalid property name.
Not
There is no need to return fdt at the end of create_fdt() because
it's already saved in s->fdt. Other machines (sifive_u, spike)
don't do it neither.
Signed-off-by: Bin Meng
Reviewed-by: Chih-Min Chao
Reviewed-by: Philippe Mathieu-Daudé
---
Changes in v3: None
Changes in v2: None
hw/riscv/vi
To keep in sync with Linux kernel device tree, generate hfclk and
rtcclk nodes in the device tree, to be referenced by PRCI node.
Signed-off-by: Bin Meng
---
Changes in v3: None
Changes in v2: None
hw/riscv/sifive_u.c | 23 +++
include/hw/riscv/sifive_u.h | 2 ++
2
Now that we have added PRCI nodes, update existing UART and ethernet
nodes to use PRCI as their clock sources, to keep in sync with the
Linux kernel device tree.
With above changes, the previously handcrafted "/soc/ethclk" node is
no longer needed. Remove it.
Signed-off-by: Bin Meng
---
Changes
This adds an OTP memory with a given serial number to the sifive_u
machine. With such support, the upstream U-Boot for sifive_fu540
boots out of the box on the sifive_u machine.
Signed-off-by: Bin Meng
---
Changes in v3: None
Changes in v2: None
hw/riscv/sifive_u.c | 5 +
include/h
The Linux kernel SiFive UART driver expects an aliases node to be
present in the device tree, from which the driver extracts the port
number from "serial#" in the aliases node.
Signed-off-by: Bin Meng
---
Changes in v3: None
Changes in v2: None
hw/riscv/sifive_u.c | 2 ++
1 file changed, 2 ins
This adds a simple PRCI model for FU540 (sifive_u). It has different
register layout from the existing PRCI model for FE310 (sifive_e).
Signed-off-by: Bin Meng
---
Changes in v3: None
Changes in v2: None
hw/riscv/Makefile.objs | 1 +
hw/riscv/sifive_u_prci.c | 163 +
Current SiFive PRCI model only works with sifive_e machine, as it
only emulates registers or PRCI block in the FE310 SoC.
Rename the file name to make it clear that it is for sifive_e.
Signed-off-by: Bin Meng
Reviewed-by: Chih-Min Chao
---
Changes in v3: None
Changes in v2: None
hw/riscv/Mak
Currently the PRCI register block size is set to 0x8000, but in fact
0x1000 is enough, which is also what the manual says.
Signed-off-by: Bin Meng
Reviewed-by: Chih-Min Chao
---
Changes in v3: None
Changes in v2: None
hw/riscv/sifive_e_prci.c | 2 +-
include/hw/riscv/sifive_e_prci.h |
This implements a simple model for SiFive FU540 OTP (One-Time
Programmable) Memory interface, primarily for reading out the
stored serial number from the first 1 KiB of the 16 KiB OTP
memory reserved by SiFive for internal use.
Signed-off-by: Bin Meng
---
Changes in v3: None
Changes in v2: None
OpenSBI for fu540 does DT fix up (see fu540_modify_dt()) by updating
chosen "stdout-path" to point to "/soc/serial@...", and U-Boot will
use this information to locate the serial node and probe its driver.
However currently we generate the UART node name as "/soc/uart@...",
causing U-Boot fail to f
With heterogeneous harts config, the PLIC hart topology configuration
string are "M,MS,.." because of the monitor hart #0.
Suggested-by: Fabien Chouteau
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v3: None
Changes in v2: None
hw/riscv/sifive_u.c | 7 ---
1 file c
Add PRCI mmio base address and size mappings to sifive_u machine,
and generate the corresponding device tree node.
Signed-off-by: Bin Meng
---
Changes in v3: None
Changes in v2: None
hw/riscv/sifive_u.c | 21 -
include/hw/riscv/sifive_u.h | 1 +
2 files changed, 21
The FU540-C000 includes a 64-bit E51 RISC-V core and four 64-bit U54
RISC-V cores. Currently the sifive_u machine only populates 4 U54
cores. Update the max cpu number to 5 to reflect the real hardware,
and pass "cpu-type" to populate heterogeneous harts.
The cpu nodes in the generated DTS have be
sifive_u machine does not use PRCI as of today. Remove the prci
header inclusion.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v3: None
Changes in v2: None
hw/riscv/sifive_u.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
This updates the UART base address and IRQs to match the hardware.
Signed-off-by: Bin Meng
Reviewed-by: Jonathan Behrens
Acked-by: Alistair Francis
Reviewed-by: Chih-Min Chao
---
Changes in v3:
- update IRQ numbers of both UARTs to match hardware as well
Changes in v2: None
hw/riscv/sifiv
It should use SIFIVE_PRCI_HFXOSCCFG_RDY and SIFIVE_PRCI_HFXOSCCFG_EN
for hfxosccfg register programming.
Signed-off-by: Bin Meng
Acked-by: Alistair Francis
Reviewed-by: Chih-Min Chao
Reviewed-by: Philippe Mathieu-Daudé
---
Changes in v3: None
Changes in v2: None
hw/riscv/sifive_e_prci.c | 2
Some of the properties only have 1 cell so we should use
qemu_fdt_setprop_cell() instead of qemu_fdt_setprop_cells().
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v3: None
Changes in v2: None
hw/riscv/sifive_u.c | 16
hw/riscv/virt.c | 24 +
At present we only allow symmetric harts to be created. In order to
support heterogeneous harts like SiFive FU540, update hart array's
"cpu-type" property to allow cpu type to be set per hart, separated
by delimiter ",". The frist cpu type before the delimiter is assigned
to hart 0, and the second
It is not useful if we only have one management CPU.
Signed-off-by: Bin Meng
---
Changes in v3:
- use management cpu count + 1 for the min_cpus
Changes in v2:
- update the file header to indicate at least 2 harts are created
hw/riscv/sifive_u.c | 5 +++--
1 file changed, 3 insertions(+), 2 d
Group SiFive E and U cpu type defines into one header file.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
---
Changes in v3: None
Changes in v2: None
include/hw/riscv/sifive_cpu.h | 31 +++
include/hw/riscv/sifive_e.h
Currently riscv_harts_realize() creates all harts based on the
same cpu type given in the hart array property. With current
implementation it can only create symmetric harts. Exact the
hart realize to a separate routine in preparation for supporting
heterogeneous hart arrays.
Signed-off-by: Bin Me
As of today, the QEMU 'sifive_u' machine is a special target that does
not boot the upstream OpenSBI/U-Boot firmware images built for the real
SiFive HiFive Unleashed board. Hence OpenSBI supports a special platform
"qemu/sifive_u". For U-Boot, the sifive_fu540_defconfig is referenced
in the OpenSB
"linux,phandle" property is optional. Remove all instances in the
sifive_u and virt machine device tree.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v3: None
Changes in v2: None
hw/riscv/sifive_u.c | 3 ---
hw/riscv/virt.c | 3 ---
2 files changed, 6 deletions(-)
Other users are having similar issues:
https://github.com/virtio-win/kvm-guest-drivers-windows/issues/402
https://www.reddit.com/r/VFIO/comments/cc2473/virtio_network_drivers_failing_on_win10_guest/etk6f6i/
** Bug watch added: github.com/virtio-win/kvm-guest-drivers-windows/issues #402
https:/
Hi Palmer,
On Tue, Aug 6, 2019 at 1:04 AM Alistair Francis wrote:
>
> On Fri, Aug 2, 2019 at 11:08 PM Bin Meng wrote:
> >
> > Currently the make rules are wrongly using qemu/virt opensbi image
> > for sifive_u machine. Correct it.
> >
> > Signed-off-by: Bin Meng
>
> Good catch.
>
> @Palmer Dabb
93 matches
Mail list logo
