[Qemu-devel] tracing memory accesses

[Qemu-devel] tracing memory accesses

[Màrius Montón]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

Hello,

I've been working for a while adding SystemC capabilities to QEMU (in short, SystemC is a C++ extension to describe HW and we are using it to add new peripherals to QEMU) (http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4374971)

Now it's time to move a whole system to a SystemC described one but the CPU. My plan is to use QEMU CPU emulation and substitute all peripherals by its SystemC description and communicate using any sort of bus in SystemC too.

So I need to capture all memory accesses from CPU to Memory. I've been looking at code, and I can see that ldq_phys, ldl_phys (in exec.c) are used to load from
memory to CPU, but I'm not able to see what functions are used to manage stores from CPU to memory. I can see some equivalent functions called stl_phys_notdirty and stl_phys, but they never used (I'm focused in ARM platforms).

Do you have any hint about that? Do you think managing these functions is enough to capture all data moving from CPU to RAM?

Thank you!

Màrius

P.S.: I noticed that Argos did similar work, but since they are focused on a very different target, this work should be started from scratch.



[-- Attachment #2: marius_monton.vcf --]
[-- Type: text/x-vcard, Size: 369 bytes --]

begin:vcard
fn;quoted-printable:M=C3=A0rius Monton
n;quoted-printable:Monton;M=C3=A0rius
org:CEPHIS-UAB
adr;quoted-printable:Bellaterra;;QC-2090D, ETSE. Campus de la UAB;Cerdanyola del Vall=C3=A8s;;08015;Spain
email;internet:marius.monton@uab.cat
title:R&D Engineer
tel;work:+34 93 581 35 34
x-mozilla-html:TRUE
url:cephis.uab.cat
version:2.1
end:vcard

Re: [Qemu-devel] tracing memory accesses

[Erik de Castro Lopo]

Màrius Montón wrote:

> I've been working for a while adding SystemC capabilities to QEMU
> (in short, SystemC is a C++ extension to describe HW and we are
> using it to add new peripherals to QEMU)
>(http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4374971)

I'd love to read that article but is seems to be locked behind some
sort of knowledge firewall. Is that article available elsewhere?

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Testing can prove the presence of bugs, but never their absence."
  -- Edsger Dijkstra

Re: [Qemu-devel] tracing memory accesses

[Laurent Desnogues]

On Tue, Nov 11, 2008 at 12:10 PM, Erik de Castro Lopo
<mle+tools@mega-nerd.com> wrote:
> Màrius Montón wrote:
>
>> I've been working for a while adding SystemC capabilities to QEMU
>> (in short, SystemC is a C++ extension to describe HW and we are
>> using it to add new peripherals to QEMU)
>>(http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4374971)
>
> I'd love to read that article but is seems to be locked behind some
> sort of knowledge firewall. Is that article available elsewhere?

http://bscw.cephis.uab.es/~marius/docs/isie07.pdf


Laurent

Re: [Qemu-devel] tracing memory accesses

[Màrius Montón]

[-- Attachment #1.1: Type: text/plain, Size: 566 bytes --]

Erik de Castro Lopo wrote:
> Màrius Montón wrote:
>
>   
>> I've been working for a while adding SystemC capabilities to QEMU
>> (in short, SystemC is a C++ extension to describe HW and we are
>> using it to add new peripherals to QEMU)
>> (http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4374971)
>>     
>
> I'd love to read that article but is seems to be locked behind some
> sort of knowledge firewall. Is that article available elsewhere?
>
> Erik
>   

here you have http://bender.cephis.uab.es/~marius/docs/isie07.pdf

Màrius


[-- Attachment #1.2: Type: text/html, Size: 1190 bytes --]

[-- Attachment #2: marius_monton.vcf --]
[-- Type: text/x-vcard, Size: 369 bytes --]

begin:vcard
fn;quoted-printable:M=C3=A0rius Monton
n;quoted-printable:Monton;M=C3=A0rius
org:CEPHIS-UAB
adr;quoted-printable:Bellaterra;;QC-2090D, ETSE. Campus de la UAB;Cerdanyola del Vall=C3=A8s;;08015;Spain
email;internet:marius.monton@uab.cat
title:R&D Engineer
tel;work:+34 93 581 35 34
x-mozilla-html:TRUE
url:cephis.uab.cat
version:2.1
end:vcard

Re: [Qemu-devel] tracing memory accesses

[Blue Swirl]

On 11/11/08, Màrius Montón <marius.monton@uab.cat> wrote:
> Hello,
>
>  I've been working for a while adding SystemC capabilities to QEMU (in short, SystemC is a C++ extension to describe HW and we are using it to add new peripherals to QEMU) (http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4374971)
>
>  Now it's time to move a whole system to a SystemC described one but the CPU. My plan is to use QEMU CPU emulation and substitute all peripherals by its SystemC description and communicate using any sort of bus in SystemC too.
>
>  So I need to capture all memory accesses from CPU to Memory. I've been looking at code, and I can see that ldq_phys, ldl_phys (in exec.c) are used to load from
>  memory to CPU, but I'm not able to see what functions are used to manage stores from CPU to memory. I can see some equivalent functions called stl_phys_notdirty and stl_phys, but they never used (I'm focused in ARM platforms).
>
>  Do you have any hint about that? Do you think managing these functions is enough to capture all data moving from CPU to RAM?

The loads and stores check the TLB if the address has been translated
(see for example generic version in softmmu_header.h). If not,
cpu_arm_mmu_fault is called to translate the address. After that, the
entry is added to TLB and the access is retried.

On subsequent accesses (also for writes if the permissions allow)
there is only a TLB lookup followed by a raw access.

Capturing all accesses transparently would need stacking of devices or
generic bus/DMA system, but we have neither. Patches welcome :-)

Less transparently this could be handled so that one device registers
that it handles all physical address space, including RAM. No other
devices register anything. If you need to access other devices, the
access functions of other devices can be called directly from the all
memory device, RAM similarly. I don't know if DMA would work.