[Qemu-devel] Benchmarking activities

[Qemu-devel] Benchmarking activities

[Ben Vogler]

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

Hi QEMU devel team,

 

I work for Toyota Technical Centre Australia in the software department. We are currently conducting benchmarking on a broad spectrum of virtual platform simulators. I was wondering if I could ask you guys a few question about QEMU, however I understand if it is too much to ask. Below is a list of questions I have:

 

-          I have seen examples of QEMU processor cores being wrapped in SystemC and used in OSCI based virtual systems - is this the general approach, or is there other/better ways of going about using QEMU not as an emulator (such as VMware), but as a simulator?

-          Is there full backwards compatibility between versions of QEMU?

-          I have been looking but could not find a complete list of processor core models supported by QEMU. I have seen there are processors from Sparc, ARM, MIPS, but are there any core models from NEC, or Renesas in particular? Would you please be able to point me in the right direction?

 

The rest of my questions are based on the assumption that QEMU IP will be used in a virtual system simulation, rather than emulation.

 

-          Is co-simulation possible? For example, connecting an engine model running in Dymola to the QEMU (processor model) based virtual system simulator.

-           Are there any inbuilt data tracing features? For example, hardware signal tracing, register monitoring etc.

 

 

Thanks for your time.

 

 

Regards, 

 

TOYOTA TECHNICAL CENTER AUSTRALIA
Ben Vogler            ベン・ヴォグラ
Software Engineer
Software Development Group
611-633 Blackburn Road
Notting Hill, VIC 3168
Email:    bvogler@toyotatech.com.au <mailto:bvogler@toyotatech.com.au> 

Phone:  +61 3 9501 5226

Confidential - do not forward this email.

P  Please consider the environment before printing this e-mail

 


[-- Attachment #2: Type: text/html, Size: 12562 bytes --]

Re: [Qemu-devel] Benchmarking activities

[Blue Swirl]

2011/6/27 Ben Vogler <bvogler@toyotatech.com.au>:
> Hi QEMU devel team,
>
>
>
> I work for Toyota Technical Centre Australia in the software department. We
> are currently conducting benchmarking on a broad spectrum of virtual
> platform simulators. I was wondering if I could ask you guys a few question
> about QEMU, however I understand if it is too much to ask. Below is a list
> of questions I have:
>
>
>
> -          I have seen examples of QEMU processor cores being wrapped in
> SystemC and used in OSCI based virtual systems – is this the general
> approach, or is there other/better ways of going about using QEMU not as an
> emulator (such as VMware), but as a simulator?

Maybe this report from QEMU User Forum may help:
http://lists.nongnu.org/archive/html/qemu-devel/2011-03/msg02065.html

> -          Is there full backwards compatibility between versions of QEMU?

In some cases (maybe x86 only) there is migration compatibility
between versions. In other cases this effort has not been considered
worthwhile.

> -          I have been looking but could not find a complete list of
> processor core models supported by QEMU. I have seen there are processors
> from Sparc, ARM, MIPS, but are there any core models from NEC, or Renesas in
> particular? Would you please be able to point me in the right direction?

Those are not supported. Each emulator can list the CPU models with
flag -cpu '?'.

>
>
>
> The rest of my questions are based on the assumption that QEMU IP will be
> used in a virtual system simulation, rather than emulation.
>
>
>
> -          Is co-simulation possible? For example, connecting an engine
> model running in Dymola to the QEMU (processor model) based virtual system
> simulator.

No idea.

> -           Are there any inbuilt data tracing features? For example,
> hardware signal tracing, register monitoring etc.

Tracing is quite new addition, so far it's only used for development
or debugging QEMU point of view I think.

>
>
>
>
> Thanks for your time.
>
>
>
>
>
> Regards,
>
>
>
> TOYOTA TECHNICAL CENTER AUSTRALIA
> Ben Vogler            ベン・ヴォグラ
> Software Engineer
> Software Development Group
> 611-633 Blackburn Road
> Notting Hill, VIC 3168
> Email:    bvogler@toyotatech.com.au
>
> Phone:  +61 3 9501 5226
>
> Confidential - do not forward this email.
>
> P  Please consider the environment before printing this e-mail
>
>

Re: [Qemu-devel] Benchmarking activities

[Stefan Hajnoczi]

On Fri, Jul 1, 2011 at 8:32 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> 2011/6/27 Ben Vogler <bvogler@toyotatech.com.au>:
>> -           Are there any inbuilt data tracing features? For example,
>> hardware signal tracing, register monitoring etc.
>
> Tracing is quite new addition, so far it's only used for development
> or debugging QEMU point of view I think.

I think you are referring to hardware model debugging and logging.
The QEMU "tracing" mechanism that Blue Swirl mentioned is a
DTrace/SystemTap style tool for observing QEMU internals and not what
you are looking for.

QEMU is not cycle-accurate and typically only presents the
register-level hardware interfaces to the VM.  We don't necessarily
model hardware state and connections.  However, the QEMU User Forum
link that Blue Swirl posted includes information from people who are
using QEMU for similar purposes as you.

Stefan

Re: [Qemu-devel] Benchmarking activities

[Edgar E. Iglesias]

On Sat, Jul 02, 2011 at 09:32:37AM +0100, Stefan Hajnoczi wrote:
> On Fri, Jul 1, 2011 at 8:32 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> > 2011/6/27 Ben Vogler <bvogler@toyotatech.com.au>:
> >> -           Are there any inbuilt data tracing features? For example,
> >> hardware signal tracing, register monitoring etc.
> >
> > Tracing is quite new addition, so far it's only used for development
> > or debugging QEMU point of view I think.
> 
> I think you are referring to hardware model debugging and logging.
> The QEMU "tracing" mechanism that Blue Swirl mentioned is a
> DTrace/SystemTap style tool for observing QEMU internals and not what
> you are looking for.
> 
> QEMU is not cycle-accurate and typically only presents the
> register-level hardware interfaces to the VM.  We don't necessarily
> model hardware state and connections.  However, the QEMU User Forum
> link that Blue Swirl posted includes information from people who are
> using QEMU for similar purposes as you.

Hi I recently added a link on the wiki to yet another hacked version.

http://edgarigl.github.com/tlmu/

Wraps QEMU into a TLM-2.0 module with TLM initiator sockets for QEMU
to make access to the TLM world and with target sockets for TLM to
make accesses into QEMU. There's a simple SystemC TLM-2.0 example
on the git.

Cheers

Re: [Qemu-devel] Benchmarking activities

[Andreas Färber]

Am 02.07.2011 um 10:32 schrieb Stefan Hajnoczi:

> On Fri, Jul 1, 2011 at 8:32 PM, Blue Swirl <blauwirbel@gmail.com>  
> wrote:
>> 2011/6/27 Ben Vogler <bvogler@toyotatech.com.au>:
>>> -           Are there any inbuilt data tracing features? For  
>>> example,
>>> hardware signal tracing, register monitoring etc.
>>
>> Tracing is quite new addition, so far it's only used for development
>> or debugging QEMU point of view I think.
>
> I think you are referring to hardware model debugging and logging.
> The QEMU "tracing" mechanism that Blue Swirl mentioned is a
> DTrace/SystemTap style tool for observing QEMU internals and not what
> you are looking for.

I believe Lluís (cc'ed) has worked on using/extending the trace  
framework to instrument guests.

QEMU has a built-in GDB server, so you can debug your code and inspect  
registers.
The QEMU monitor is another way to inspect registers beyond those  
shown in GDB.

Andreas

Re: [Qemu-devel] Benchmarking activities

[Lluís]

Andreas Färber writes:

> Am 02.07.2011 um 10:32 schrieb Stefan Hajnoczi:
>> On Fri, Jul 1, 2011 at 8:32 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
>>> 2011/6/27 Ben Vogler <bvogler@toyotatech.com.au>:
>>>> -           Are there any inbuilt data tracing features? For example,
>>>> hardware signal tracing, register monitoring etc.
>>> 
>>> Tracing is quite new addition, so far it's only used for development
>>> or debugging QEMU point of view I think.
>> 
>> I think you are referring to hardware model debugging and logging.
>> The QEMU "tracing" mechanism that Blue Swirl mentioned is a
>> DTrace/SystemTap style tool for observing QEMU internals and not what
>> you are looking for.

> I believe Lluís (cc'ed) has worked on using/extending the trace framework to
> instrument guests.

Yes, the idea is to have a set of generic guest events (e.g.,
information during instruction fetch, privilege-level change, control
flow instructions, etc.) that are target agnostic.

This is coupled with the possibility to statically instrument tracing
points with user-provided code, so that almost anything can be done with
these few basic pieces, ranging from code instrumentation tools a-la
PIN, information flow tracking analysis or even cycle-accurate
simulations driven by QEMU as the target emulation component. All with a
target-agnostic interface that is common to both system-wide and user
application functional simulation.

I've also modified the timing infrasructure to have a more accurate
guest cycle counter that is able to handle a per-vCPU CPI (cycles per
instruction), as the current approach in QEMU is not adecuate for
cycle-accurate simulations.

I've been developing all these changes in small self-contained patches,
as my intention is to work towards having these generic pieces
integrated into QEMU proper, so that everybody can benefit from that
work, as well as avoid having a separate project that will otherwise
quickly fall behind QEMU's codebase.

What I still haven't decided is whether this generic interface should
provide the user with a way to modify the behaviour of the guest, like
skipping the execution of QEMU-generated code and instead execute
user-provided code to change the semantics of certain instructions
without having to hack directly into QEMU.


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth