[Qemu-devel] Code source modifying

[Qemu-devel] Code source modifying

[Ormaetxea Xabier]

Hello!

I need  to modify the source code of QEMU to apply a little change. My final idea is to prove the utility of a virtual platform as a way of reusing software designed for an obsolete hardware. For that I've created a "real timer", connected to my board. Now... the problem:

My standalone program writes "0xffffffff" in the position 0x95000000 when the timer should start, and "0x00000000" when it have to finish. I want to modify the code so every single (standalone) program step reads the virtual 0x95000000 and changes the value of a gpio. But I can't find how I can read from the source code the virtual memory, and I can't find neither where/how does the program process (step by step) the standalone program.

I don't know if I have explained well my doubts...

Thankyou in advance!

Xabi

Re: [Qemu-devel] Code source modifying

[Peter Maydell]

On 10 July 2017 at 10:14, Ormaetxea Xabier <xormaetxea@ikerlan.es> wrote:
> My standalone program writes "0xffffffff" in the position 0x95000000
> when the timer should start, and "0x00000000" when it have to finish.
> I want to modify the code so every single (standalone) program step
> reads the virtual 0x95000000 and changes the value of a gpio. But I
> can't find how I can read from the source code the virtual memory,
> and I can't find neither where/how does the program process (step
> by step) the standalone program.

QEMU doesn't really work that way. What we do is take blocks of the
guest binary (usually up to the next branch instruction), translate
the whole block to native host binary code, and then execute those
translated blocks. So our main execution loop (cpu_exec()) is
basically a loop that does:
 * handle any pending interrupt or exception work
 * find previously translated block for this PC
   (and translate it if it didn't already exist)
 * execute that TB (which will execute multiple guest insns
   and may jump directly to another TB without coming back to C code)

Do you really mean virtual addresses here? That is very weird:
hardware doesn't do that -- timer devices are at fixed physical
addresses which the guest can then choose to map where they like
in the virtual address space using the MMU.

thanks
-- PMM

Re: [Qemu-devel] Code source modifying

[Ormaetxea Xabier]

Hi Peter!

Ah sorry, I thought that replying to your message it was somehow redirected to the mailing list. So, every-time I respond, I have to do it to qemu-devel@nongnu.org? Or a CC it's enough? Sorry for my ignorance...

Anyway, do you imagine how can I make this "virtual world"-"real world" connection? I mean, is there an easy way of connecting an execution from the standalone with the source code?

Thank you for your work!

Xabi

-----Mensaje original-----
De: Peter Maydell [mailto:peter.maydell@linaro.org] 
Enviado el: lunes, 10 de julio de 2017 11:58
Para: Ormaetxea Xabier
Asunto: Re: [Qemu-devel] Code source modifying

It's really better to keep threads on the public mailing lists,
that way the answers help everybody (and anybody who knows the
answer can reply)...

Anyway, you cannot do what you're trying to do the way you're
trying to do it.

thanks
-- PMM

On 10 July 2017 at 10:40, Ormaetxea Xabier <xormaetxea@ikerlan.es> wrote:
> Hello Peter!
>
> I will use the "read every loop" in cpu_exec(), I suppose it’s the "best" place to do it.
>
> And yes, I really mean virtual address... Let's see if I can explain well myself (not the best at english).
> The standalone program works over the virtual platform, so when I want the exterior timer to start counting I will use a:
>
> 0x95000000*=0xffffffff
>
> And when I want to finish it:
>
> 0x95000000*=0x00000000
>
> Now, from the code source, I need to read in every step (let's say every cpu_exec() loop) that virtual position. Like connecting the virtual and real addresses.
>
> Something just like:
>
> if (0x95000000*==0xffffffff){
>         system("echo 1 > /sys/class/gpio/gpio913/value");
> }
> else{
>         system("echo 0 > /sys/class/gpio/gpio913/value");
> }
>
> But I don't know where it maps my virtual (0x95000000) memory. So... can't do 0x95000000*==0xffffffff.
>
> Thank you for your help!
>
> Xabi
>
>
>
> -----Mensaje original-----
> De: Peter Maydell [mailto:peter.maydell@linaro.org]
> Enviado el: lunes, 10 de julio de 2017 11:26
> Para: Ormaetxea Xabier
> CC: qemu-devel@nongnu.org
> Asunto: Re: [Qemu-devel] Code source modifying
>
> On 10 July 2017 at 10:14, Ormaetxea Xabier <xormaetxea@ikerlan.es> wrote:
>> My standalone program writes "0xffffffff" in the position 0x95000000
>> when the timer should start, and "0x00000000" when it have to finish.
>> I want to modify the code so every single (standalone) program step
>> reads the virtual 0x95000000 and changes the value of a gpio. But I
>> can't find how I can read from the source code the virtual memory,
>> and I can't find neither where/how does the program process (step
>> by step) the standalone program.
>
> QEMU doesn't really work that way. What we do is take blocks of the
> guest binary (usually up to the next branch instruction), translate
> the whole block to native host binary code, and then execute those
> translated blocks. So our main execution loop (cpu_exec()) is
> basically a loop that does:
>  * handle any pending interrupt or exception work
>  * find previously translated block for this PC
>    (and translate it if it didn't already exist)
>  * execute that TB (which will execute multiple guest insns
>    and may jump directly to another TB without coming back to C code)
>
> Do you really mean virtual addresses here? That is very weird:
> hardware doesn't do that -- timer devices are at fixed physical
> addresses which the guest can then choose to map where they like
> in the virtual address space using the MMU.
>
> thanks
> -- PMM

Re: [Qemu-devel] Code source modifying

[Peter Maydell]

On 10 July 2017 at 11:16, Ormaetxea Xabier <xormaetxea@ikerlan.es> wrote:
> Ah sorry, I thought that replying to your message it was somehow
> redirected to the mailing list. So, every-time I respond, I have
> to do it to qemu-devel@nongnu.org? Or a CC it's enough? Sorry for
> my ignorance...

Yes, you just have to send mail to: or cc: the qemu-devel
address.

> Anyway, do you imagine how can I make this "virtual world"-"real world"
> connection? I mean, is there an easy way of connecting an execution
> from the standalone with the source code?

Two things:

(1) you should try to make your interface with the emulator
map more closely to what existing examples do. "Write to
a virtual address in RAM that is monitored" is really weird and
will be a pain to implement.

What makes more sense depends a bit on whether you're using
qemu-system-* (a full-system emulator of cpu and devices) or
qemu-* (which just emulate a single Linux process by intercepting
system calls). For full-system, you can for instance provide
a device model that sits at a known physical address. Or you
can use the kind of interface that OSes might use to talk to
firmware (like an SMC instruction on ARM -- our PSCI
implementation works this way).

For linux-user the simplest thing is obviously just to
implement a syscall (or to use the existing timer ones!)

(2) you don't want to do this by "check something every
time round an execution loop" because this will make the
performance very bad. What you need to do is arrange that
when the guest does some action (write to physical address,
make SMC call, make system call) you get control and can
implement your behaviour there. (This is another reason
why write-to-virtual-address is a suboptimal choice: it's
harder to get control for that.)

thanks
-- PMM

Re: [Qemu-devel] Code source modifying

[Ormaetxea Xabier]

Hi Peter,

One last question if possible :)

I've changed the idea of "connecting the virtual and real worlds" to an easy (and ugly) way. I will use the decode function, where every single execution is translated from assembly language to binary code. There, comparing each assembly code with the ones I know from the .elf I can modify the value of my gpio.

But, the problem is that this way would only be reliable if the starting and finishing assembly codes where in isolated "Translation blocks". So, in this way, the time between those two executions is the one I really want to measure (translating and executing my app).

You told me those translated blocks are usually "separated" by branches. I tried to introduce little branches in my standalone code, (little "if"-s), but didn't get anything. How can I separate my translation blocks from the standalone? Is there a way, or am I again in a wrong direction?

Thank you in advance!

Xabi

-----Mensaje original-----
De: Peter Maydell [mailto:peter.maydell@linaro.org] 
Enviado el: lunes, 10 de julio de 2017 11:26
Para: Ormaetxea Xabier
CC: qemu-devel@nongnu.org
Asunto: Re: [Qemu-devel] Code source modifying

On 10 July 2017 at 10:14, Ormaetxea Xabier <xormaetxea@ikerlan.es> wrote:
> My standalone program writes "0xffffffff" in the position 0x95000000
> when the timer should start, and "0x00000000" when it have to finish.
> I want to modify the code so every single (standalone) program step
> reads the virtual 0x95000000 and changes the value of a gpio. But I
> can't find how I can read from the source code the virtual memory,
> and I can't find neither where/how does the program process (step
> by step) the standalone program.

QEMU doesn't really work that way. What we do is take blocks of the
guest binary (usually up to the next branch instruction), translate
the whole block to native host binary code, and then execute those
translated blocks. So our main execution loop (cpu_exec()) is
basically a loop that does:
 * handle any pending interrupt or exception work
 * find previously translated block for this PC
   (and translate it if it didn't already exist)
 * execute that TB (which will execute multiple guest insns
   and may jump directly to another TB without coming back to C code)

Do you really mean virtual addresses here? That is very weird:
hardware doesn't do that -- timer devices are at fixed physical
addresses which the guest can then choose to map where they like
in the virtual address space using the MMU.

thanks
-- PMM