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
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
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
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
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
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
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.
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,
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:
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
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 +
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
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
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 --
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
---
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
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
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é
---
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 -
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
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
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
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
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.
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
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
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
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
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
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
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(-)
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
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
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
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
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
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
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
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
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
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
>
>
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
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
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
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
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
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;
> +
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
>>
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
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
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
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.
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
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 ++
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
---
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 +
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
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
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
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
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,
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
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
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 |
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
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
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
"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
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
On 8/8/19 3:39 PM, Stefan Hajnoczi wrote:
> On Wed, Aug 07, 2019 at 12:44:40PM +0530, Balamuruhan S wrote:
>> +void python_args_init_cast_int(char *args[], int arg, int pos)
>> +{
>> +args[pos]= malloc(sizeof(int));
>> +sprintf(args[pos], "%d", arg);
>> +}
> This is broken. args[pos] is
On 8/9/19 10:14 AM, David Gibson wrote:
> On Wed, Aug 07, 2019 at 09:54:55AM +0200, Cédric Le Goater wrote:
>> On 07/08/2019 09:14, Balamuruhan S wrote:
>>> Add mmio callback functions to enable homer/occ common area
>>> to emulate pstate table, occ-sensors, slw, occ static and
>>> dynamic values
On 8/9/19 10:16 AM, David Gibson wrote:
> On Wed, Aug 07, 2019 at 12:44:45PM +0530, Balamuruhan S wrote:
>> use python interface APIs in homer/occ common area emulation to
>> interact with scripts if provided else fallback to normal flow,
>> it shows how simple to use the interface to call python
On 8/7/19 3:57 PM, Philippe Mathieu-Daudé wrote:
> On 8/7/19 9:14 AM, Balamuruhan S wrote:
>> use python interface APIs in homer/occ common area emulation to
>> interact with scripts if provided else fallback to normal flow,
>> it shows how simple to use the interface to call python methods
>>
93 matches
Mail list logo
