Signed-off-by: Alexey Kardashevskiy
---
qapi/misc.json | 9 +
1 file changed, 9 insertions(+)
diff --git a/qapi/misc.json b/qapi/misc.json
index 5636f4a..399ec74 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -1491,6 +1491,10 @@
#
# List properties associated with a device.
#
+#
This adds owners/parents (which are the same, just occasionally
owner==NULL) printing for memory regions; a new '-o' flag
enabled new output.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v2:
* cleanups
---
include/exec/memory.h | 2 +-
memory.c | 69
This is a debug extension to "into mtree" to print a memory region owner/parent.
This is based on sha1
4743c23 Peter Maydell "Update version for v2.12.0 release".
Please comment. Thanks.
Alexey Kardashevskiy (2):
memory/hmp: Print owners/parents in "info mtree"
object: Handle objects with
At the moment object_get_canonical_path_component() crashes on assert()
if the object does not have a parent. Usually it is not called for
orphan objects but various HMP/QMP commands can do that (info mtree,
qom-get).
This adds few more tests in object_get_canonical_path() to prevent QEMU
from cra
On Sat, Apr 28, 2018 at 2:17 AM, Peter Maydell
wrote:
> On 2 March 2018 at 13:51, Michael Clark wrote:
> > RISC-V machine with device-tree, 16550a UART and VirtIO MMIO.
> > The following machine is implemented:
> >
> > - 'virt'; CLINT, PLIC, 16550A UART, VirtIO MMIO, device-tree
> >
> > Acked-by
I am getting the same errors while doing a "replay". Are there any
updates on the resolution/fix ?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1762179
Title:
Record and replay replay fails with:
ppc64 uses a BC instruction to call the tcg_out_qemu_ld/st
slow path. BC instruction uses a relative address encoded
on 14 bits.
The slow path functions are added at the end of the generated
instructions buffer, in the reverse order of the callers.
So more we have slow path functions more the dist
On Sat, Apr 28, 2018 at 12:26 AM, Peter Maydell
wrote:
> On 2 March 2018 at 13:51, Michael Clark wrote:
> > The RISC-V disassembler has no dependencies outside of the 'disas'
> > directory so it can be applied independently. The majority of the
> > disassembler is machine-generated from instruct
This fixes an issue when disassembling rv128 c.sqsp,
where the code erroneously fell through to c.swsp.
Cc: Palmer Dabbelt
Cc: Sagar Karandikar
Cc: Bastian Koppelmann
Cc: Peter Maydell
Signed-off-by: Michael Clark
---
disas/riscv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
dif
On Sat, Apr 28, 2018 at 5:53 AM, Richard Henderson <
richard.hender...@linaro.org> wrote:
> On 04/26/2018 09:24 PM, Michael Clark wrote:
> >
> >
> > On Fri, Apr 27, 2018 at 12:26 PM, Richard Henderson
> > mailto:richard.hender...@linaro.org>>
> wrote:
> >
> > Cc: Michael Clark mailto:m...@sifi
On 29 April 2018 at 15:44, Richard Henderson
wrote:
> On 04/27/2018 11:04 AM, Alex Bennée wrote:
>>
>> Richard Henderson writes:
>>> +elements = 8 << is_q >> size;
>>
>> That is a brain exercise for operator precedence. Would:
>>
>> elements = (is_q ? 16 : 8) >> size;
>>
>> be cleare
On 04/27/2018 02:01 PM, Michal Suchánek wrote:
> Is there any reason why the 64bit emulator would not run on 32bit
> system? The emulated 64bit system is .. emulated after all.
It does run, but it requires that the 32-bit host perform double-word
arithmetic to emulate the 64-bit guest. When the 6
On 04/27/2018 11:04 AM, Alex Bennée wrote:
>
> Richard Henderson writes:
>
>> While we have some of the scalar paths for *CVF for fp16,
>> we failed to decode the fp16 version of these instructions.
>>
>> Signed-off-by: Richard Henderson
>> ---
>> target/arm/translate-a64.c | 33 ++
On 04/28/2018 03:29 AM, Laurent Vivier wrote:
> ppc64 uses a BC instruction to call the tcg_out_qemu_ld/st
> slow path. BC instruction uses a relative address encoded
> on 14 bits.
>
> The slow path functions are added at the end of the generated
> instructions buffer, in the reverse order of the
On Fri, Apr 27, 2018 at 06:34:16PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Update the migration docs:
>
> Among other changes:
> * Added a general list of advice for device authors
> * Reordered the section on conditional state (subsections etc)
>
On 04/29/2018 12:15 PM, Rafael Kioji wrote:
> Dear all,
>
> What is the difference between these two functions? They are located in the
> file
> "tcg/tcg-op.c". Here is their header:
>
> 1. static inline void tcg_gen_ld_i64(TCGv_i64 ret, TCGv_ptr arg2,
> tcg_target_long offset)
This is used
Dear all,
What is the difference between these two functions? They are located in
the file "tcg/tcg-op.c". Here is their header:
1. static inline void tcg_gen_ld_i64(TCGv_i64 ret, TCGv_ptr arg2,
tcg_target_long offset)
2. void tcg_gen_qemu_ld_i64(TCGv_i64 val, TCGv addr, TCGArg idx,
TCGM
On Fri, Apr 27, 2018 at 10:36:33PM +0300, Marcel Apfelbaum wrote:
> On 27/04/2018 17:49, Peter Maydell wrote:
> > On 19 February 2018 at 11:43, Marcel Apfelbaum wrote:
> >> From: Yuval Shaia
> >>
> >> PVRDMA is the QEMU implementation of VMware's paravirtualized RDMA device.
> >> It works with it
Le 29/04/2018 à 09:40, Thomas Huth a écrit :
> It's the MCF5208 evaluation board, not the MCF5206 eval board.
>
> Signed-off-by: Thomas Huth
> ---
> hw/m68k/mcf5208.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
> index 7aca58542
On Fri, Apr 27, 2018 at 09:20:44PM +0300, Marcel Apfelbaum wrote:
> Hi Peter,
>
> On 27/04/2018 17:31, Peter Maydell wrote:
> > On 19 February 2018 at 11:43, Marcel Apfelbaum wrote:
> >> From: Yuval Shaia
> >>
> >> First PVRDMA sub-module - implementation of the PVRDMA device.
> >> - PVRDMA comm
It's the MCF5208 evaluation board, not the MCF5206 eval board.
Signed-off-by: Thomas Huth
---
hw/m68k/mcf5208.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
index 7aca58542e..ae3dcc98c3 100644
--- a/hw/m68k/mcf5208.c
+++ b/hw/m68k/mcf5
On Fri, Apr 27, 2018 at 03:55:16PM +0100, Peter Maydell wrote:
> On 19 February 2018 at 11:43, Marcel Apfelbaum wrote:
> > From: Yuval Shaia
> >
> > PVRDMA is the QEMU implementation of VMware's paravirtualized RDMA device.
> > It works with its Linux Kernel driver AS IS, no need for any special
22 matches
Mail list logo
