On Thu, Aug 01, 2019 at 03:49:37PM +0200, Auger Eric wrote:
> Hi Michael,
>
> On 8/1/19 3:06 PM, Michael S. Tsirkin wrote:
> > On Thu, Aug 01, 2019 at 02:15:03PM +0200, Auger Eric wrote:
> >> Hi Michael,
> >>
> >> On 7/30/19 9:35 PM, Michael S. Tsirkin wrote:
> >>> On Tue, Jul 30, 2019 at 07:21:36
On Tue, Jul 30, 2019 at 07:21:35PM +0200, Eric Auger wrote:
> When translating an address we need to check if it belongs to
> a reserved virtual address range. If it does, there are 2 cases:
>
> - it belongs to a RESERVED region: the guest should neither use
> this address in a MAP not instruct
In the past we did not have a model for PRCI, hence two handcrafted
clock nodes ("/soc/ethclk" and "/soc/uartclk") were created for the
purpose of supplying hard-coded clock frequencies. But now since we
have added the PRCI support in QEMU, we don't need them any more.
Signed-off-by: Bin Meng
Rev
With the support of heterogeneous harts and PRCI model, it's now
possible to use the OpenSBI image (PLATFORM=sifive/fu540) built
for the real hardware.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Chang
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 v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Ch
Add PRCI mmio base address and size mappings to sifive_u machine,
and generate the corresponding device tree node.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- create sifive_u_prci block directly in the machine codes, instea
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 homogeneous harts. Exact the
hart realize to a separate routine in preparation for supporting
multiple hart arrays.
Note the file header say
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.
Not like other GEM variants, the FU540-specific GEM has a management
block to control 10/100/1000M
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 v7: None
Changes in v6: None
For hfxosccfg register programming, SIFIVE_E_PRCI_HFXOSCCFG_RDY and
SIFIVE_E_PRCI_HFXOSCCFG_EN should be used.
Signed-off-by: Bin Meng
Acked-by: Alistair Francis
Reviewed-by: Chih-Min Chao
Reviewed-by: Philippe Mathieu-Daudé
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Chan
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
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,
by creating 2 CPU clusters as containers for RISC-V hart arrays to
populate heterogeneous harts.
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
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- c
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 v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
include/hw/riscv/s
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 v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- update IRQ numbe
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 v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Cha
Now that we have added a PRCI node, update existing UART and ethernet
nodes to reference PRCI as their clock sources, to keep in sync with
the Linux kernel device tree.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes
Use create_unimplemented_device() instead.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- drop patch "riscv: sifive: Move sifive_mmio_emulate() to a common place"
- n
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
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Change
The inclusion of "target/riscv/cpu.h" is unnecessary in various
sifive model drivers.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- new patch to remove the unnecessary include of target/riscv/cpu.h
Changes in v4: None
Change
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
Reviewed-by: Alistair Francis
---
Changes in v7: None
Changes in v6:
- fix incorrectly indented comment lines
- remove unneeded bracke
It is not useful if we only have one management CPU.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- use management cpu count + 1 for the min_cpus
Changes in v2:
- update the file header
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 v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
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
Reviewed-by: Alistair Francis
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes
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 v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
hw/riscv/sifive_u.c | 1 -
1 file
At present each hart's hartid in a RISC-V hart array is assigned
the same value of its index in the hart array. But for a system
that has multiple hart arrays, this is not the case any more.
Add a new "hartid-base" property so that hartid number can be
assigned based on the property value.
Signed
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
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes i
Like other binary files, the executable attribute of opensbi images
should not be set.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- new patch to remove executable attribute of opensbi images
Changes in v
Replace the call to hw_error() with qemu_log_mask(LOG_GUEST_ERROR,...)
in various sifive models.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v7: None
Changes in v6: None
Changes in v5:
- new patch to change to use qemu_log_mask(LOG_GUEST_ERROR,...) instead
in various
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.
This also prefix "sifive_e"/"SIFIVE_E" for all macros, variables
and functions.
Signed-off-by: Bin Meng
Reviewe
"linux,phandle" property is optional. Remove all instances in the
sifive_u, virt and spike machine device trees.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- remove 2 more "linux,phandle" instances in sif
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
There is no need to return fdt at the end of create_fdt() because
it's already saved in s->fdt.
Signed-off-by: Bin Meng
Reviewed-by: Chih-Min Chao
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
---
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
I have access to lots of Power hardware, and happy to test and help
however I can! Thanks, Mark!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1841990
Title:
instruction 'denbcdq' misbehaving
Sta
Hi Julia,
On 8/27/19 5:58 PM, Julia Suvorova wrote:
On Mon, 2018-09-17 at 22:57 +0800, Zihan Yang wrote:
Hi all
Here is a minimal working version of supporting multiple pci domains.
Hi Zihan,
Do you plan to continue working on this project?
Since the last submission was long ago we can safe
On 8/28/19 5:23 PM, Sukrit Bhatnagar wrote:
vmstate_pvrdma describes the PCI and MSIX states as well as the dma
address for dsr and the gid table of device.
vmstate_pvrdma_gids describes each gid in the gid table.
pvrdma_post_save() does the job of unregistering gid entries from the
backend d
On 8/28/19 5:23 PM, Sukrit Bhatnagar wrote:
Map to DSR only when there is no mapping done already i.e., when
dev->dsr_info.dsr is NULL. This allows the rest of mappings and
ring inits to be done by calling load_dsr() when DSR has already
been mapped to, somewhere else.
Move free_dsr() out of
Hi Sukrit,
On 8/28/19 5:23 PM, Sukrit Bhatnagar wrote:
This series enables the migration of various GIDs used by the device.
This is in addition to the successful migration of PCI and MSIX states
as well as various DMA addresses and ring page information.
We have a setup having two hosts a
Hi Yuval,
On 8/18/19 4:21 PM, Yuval Shaia wrote:
The virtual address that is provided by the guest in post_send and
post_recv operations is related to the guest address space. This address
space is unknown to the HCA resides on host so extra step in these
operations is needed to adjust the addre
On 8/18/19 4:21 PM, Yuval Shaia wrote:
The function reg_mr_iova is an enhanced version of ibv_reg_mr function
that can help to easly register and use guest's MRs.
Add check in 'configure' phase to detect if we have libibverbs with this
support.
Signed-off-by: Yuval Shaia
---
configure | 2
Hi Yuval,
On 8/18/19 4:21 PM, Yuval Shaia wrote:
The virtual address that is provided by the guest in post_send and
post_recv operations is related to the guest address space. This
address
space is unknown to the HCA resides on host so extra step in these
operations is needed to adjust the addre
Thanks for the report Paul (and also the investigation work Philippe).
So yes it seems the DFP code is another fallout from the conversion of
the floating point registers over to host-endian/VSR format. I've had a
quick look at this and it seems that the simple fix to compensate for
the FP registe
于2019年8月31日周六 下午11:46写道：
> Patchew URL:
> https://patchew.org/QEMU/20190831153922.121308-1-liq...@163.com/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
>
> Type: series
> Message-id: 20190831153922.121308-1-liq...@163.com
> Subject
fangying 于2019年8月31日周六 上午8:45写道：
> Hi Gerd,
>
> Memory leak is observed in zrle_compress_data when we are doing some
> AddressSanitizer tests. The leak stack is as bellow:
>
> =
> ==47887==ERROR: LeakSanitizer: detected memory leaks
Patchew URL: https://patchew.org/QEMU/20190831153922.121308-1-liq...@163.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190831153922.121308-1-liq...@163.com
Subject: [Qemu-devel] [PATCH] vnc: fix memory leak when
Currently when qemu receives a vnc connect, it creates a 'VncState' to
represent this connection. In 'vnc_worker_thread_loop' it creates a
local 'VncState'. The connection 'VcnState' and local 'VncState' exchange
data in 'vnc_async_encoding_start' and 'vnc_async_encoding_end'.
In 'zrle_compress_dat
09.08.2019 19:14, Max Reitz wrote:
> This patch adds some tests on how commit copes with filter nodes.
>
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/040 | 177 +
> tests/qemu-iotests/040.out | 4 +-
> 2 files changed, 179 insertions(+), 2 de
09.08.2019 19:14, Max Reitz wrote:
> This patch adds some test cases how mirroring relates to filters. One
> of them tests what happens when you mirror off a filtered COW node, two
> others use the mirror filter node as basically our only example of an
> implicitly created filter node so far (besi
09.08.2019 19:14, Max Reitz wrote:
> This patch adds some tests on how commit copes with filter nodes.
>
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/040 | 177 +
> tests/qemu-iotests/040.out | 4 +-
> 2 files changed, 179 insertions(+), 2 de
09.08.2019 19:13, Max Reitz wrote:
> This includes some permission limiting (for example, we only need to
> take the RESIZE permission if the base is smaller than the top).
>
> Signed-off-by: Max Reitz
> ---
> block/block-backend.c | 16 +---
> block/commit.c| 96 ++
09.08.2019 19:13, Max Reitz wrote:
> This includes some permission limiting (for example, we only need to
> take the RESIZE permission for active commits where the base is smaller
> than the top).
>
> Signed-off-by: Max Reitz
> ---
> block/mirror.c | 117 ++--
23.08.2019 17:37, Eric Blake wrote:
> Commit fe0480d6 and friends added BDRV_REQ_NO_FALLBACK as a way to
> avoid wasting time on a preliminary write-zero request that will later
> be rewritten by actual data, if it is known that the write-zero
> request will use a slow fallback; but in doing so, co
31.08.2019 2:37, Eric Blake wrote:
> On 8/30/19 1:07 PM, Vladimir Sementsov-Ogievskiy wrote:
>> 23.08.2019 17:37, Eric Blake wrote:
>>> Commit fe0480d6 and friends added BDRV_REQ_NO_FALLBACK as a way to
>>> avoid wasting time on a preliminary write-zero request that will later
>>> be rewritten by a
The NeXTcube uses a linear framebuffer with 4 greyscale colors and
a fixed resolution of 1120 * 832.
This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-fb.c
and altered to fit the latest interface of the current QEMU
The NeXTcube uses a normal 8530 serial controller, so we can simply use
our normal "escc" device here.
While we're at it, also add a boot-serial-test for the next-cube machine,
now that the serial output works.
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: Thomas Huth
---
hw/m68k/Kconfig
It is still quite incomplete (no SCSI, no floppy emulation, no network,
etc.), but the firmware already shows up the debug monitor prompt in the
framebuffer display, so at least the very basics are already working.
This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
https://git
I don't have much clue about the NeXT hardware, but at least I know now
the source files a little bit, so I volunteer to pick up patches and send
PULL requests for them until someone else with more knowledge steps up
to do this job instead.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Thoma
During Google Summer of Code 2011, Bryce Lanham added the possibility to
emulate the NeXTcube machine in QEMU, e.g. see these URLs for some details:
https://wiki.qemu.org/Google_Summer_of_Code_2011#NeXT_machines_system_emulation
https://lists.gnu.org/archive/html/qemu-devel/2011-08/msg02158.html
It is likely still quite incomplete (e.g. mouse and interrupts are not
implemented yet), but it is good enough for keyboard input at the firmware
monitor.
This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-kbd.c
and a
From: Laurent Vivier
On Sparc and PowerMac, the bit 0 of the address selects the register
type (control or data) and bit 1 selects the channel (B or A).
On m68k Macintosh and NeXTcube, the bit 0 selects the channel and
bit 1 the register type.
This patch introduces a new parameter (bit_swap) to
60 matches
Mail list logo
