I'm trying to use the deterministic record/replay feature, and I would
like to know which commit I should take to get it work.
In RC0 it seems to be broken. I tried pre-MTTCG commit 2421f381dc, as
>>
>>> Can you retry with the latest rc? There were some fixes regarding rr since
>>>
>> Hi,
>>
>> I'm trying to use the deterministic record/replay feature, and I would
>> like to know which commit I should take to get it work.
>> In RC0 it seems to be broken. I tried pre-MTTCG commit 2421f381dc, as
> Can you retry with the latest rc? There were some fixes regarding rr since
> rc
Hi,
I'm trying to use the deterministic record/replay feature, and I would
like to know which commit I should take to get it work.
In RC0 it seems to be broken. I tried pre-MTTCG commit 2421f381dc, as
mentioned here:
http://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg02657.html
with this p
> This set of patches is related to the reverse execution and deterministic
> replay of qemu execution. It includes recording and replaying of serial
> devices
> and block devices operations.
>
> With these patches one can record and deterministically replay behavior
> of the system with connected
If I understand correctly, the most advanced MMU that QEMU emulates
for MIPS is "R4000-style" MMU - i.e. a "software-managed" TLB, where
on TLB miss QEMU just emulates exception that should be handled by the
guest OS. So, QEMU doesn't walk through the page directory, like it
does when emulating e.g
Hello,
I implemented a simple sys_bus device that only communicates through
port io. The purpose of this device is to be accessible via /dev/port
only, with no need for any additional kernel modules.
I Defined the memory region using memory_region_init_io and registered
it using sysbus_add_io.
I r
> > Here is an excerpt from r4k_map_address(), related to addresses >=
0x8000.
> > Actually, it maps 0x8010 and 0xA010 to the same physical
> > address. What's the idea behind that?
>
> 0x8010 is kseg0 whereas 0xA010 is kseg1, both segments are
> unmapped thus both refer to the
> > Here is an excerpt from r4k_map_address(), related to addresses >=
0x8000.
> > Actually, it maps 0x8010 and 0xA010 to the same physical
> > address. What's the idea behind that?
>
> 0x8010 is kseg0 whereas 0xA010 is kseg1, both segments are
> unmapped thus both refer to the
I have some issues when accessing guest Linux kernel memory above
0xC000 by means of cpu_memory_rw_debug (x86_64 host, MIPS guest),
and I'm trying to debug it.
Here is an excerpt from r4k_map_address(), related to addresses >= 0x8000.
Actually, it maps 0x8010 and 0xA010 to the same
In my QEMU-based project I would like to perform "extensive" tracing
of basic blocks (translation blocks). I.e. in addition to what the
existing tracing mechanism does, I'd like to log registers modified by
TB and memory (RAM) written by TB. As for registers, it seems to be
trivial. My main problem
Hello,
I would like to try this new functionality. What's the correct way to do
this?
I'm trying the following (after applying the patches to qemu upstream):
qemu-system-i386 mylinux.qcow2 -icount shift=7,rr=record,rrfile=record.bin
-net none
Linux gets booted, record.bin file is created.
Then I
>> I try to use cpu_memory_rw_debug() to read from 0x8xxx kernel virtual
>> address, when the guest is in user mode. Obviously, it fails.
>> Is it possible to modify some control registers to allow such an access? I
>> tried to set/clear the kernel mode bits in CP0_Status, but it doesn't help.
Hello,
I try to use cpu_memory_rw_debug() to read from 0x8xxx kernel virtual
address, when the guest is in user mode. Obviously, it fails.
Is it possible to modify some control registers to allow such an access? I
tried to set/clear the kernel mode bits in CP0_Status, but it doesn't help.
Tha
> > When debugging (via gdbstub), I would like to get the current process
> > id by a virtual address. When the virtual address is in the
> > user-space, the only way to find the current task_struct I can think
> > of is to iterate over all the task_struct's (assuming we know
> > task_init and the
Thanks for the useful info!
(Actually, my approach works as well - it was just endianness issue...)
Hello,
I need to access thread_info (linux kernel struct) of the guest from within
qemu, when the guest is in kernel mode.
To do this, I read the stack pointer and mask it with ~(stack_size - 1).
This works with x86 and ARM, but doesn't seem to work with MIPS - the
pointer points to something that
>> On x86 one can get the current PGD from CR3. What's the right way to
>> do this on ARM?
>
> What's a PGD ?
Page global directory
> However just looking at base & mask is not necessarily
> correct -- depending on the configuration of the CPU we
> might be using translation table base control r
Hello,
On x86 one can get the current PGD from CR3. What's the right way to
do this on ARM?
In a code based on an old QEMU version, I see the following:
pgd = env->cp15.c2_base0 & env->cp15.c2_base_mask;
But in the recent QEMU version c2_base0 field is absent. Instead,
there's ttbr0[] array. So s
18 matches
Mail list logo
