[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] emulation details of qemu

From: tutu sky
Subject: Re: [Qemu-devel] emulation details of qemu
Date: Fri, 29 Apr 2016 12:39:40 +0000

Magic answer, Thanks a lot Alex.
you mean GDB will be enabled for just QEMU's itself internals? It does not make 
importance or any difference for guest running on it?
if i want describe my opinion in another way, i think you said that when 
enabling GDB for QEMU, it is usable and is just important to be usable for QEMU 
internals, as a user wants to develop it or a person may want to know how he 
can watch a processor internals. Yeah?

Can GDB  be activated for multicore architectures? in order to see every core's 
internals separately?
I ask these questions because QEMU documentation is not clear enough and 
sometimes hard to understand. for example for attaching GDB to QEMU, i am 
unable to find a good and general guide. it seems it just depend on how much 
you know about GDB and how to work with. am i right?

Thanks and regards.

From: Alex Bennée <address@hidden>
Sent: Friday, April 29, 2016 12:22 PM
To: tutu sky
Cc: Stefan Hajnoczi; address@hidden
Subject: Re: [Qemu-devel] emulation details of qemu

tutu sky <address@hidden> writes:

> Yeah, thank you Alex.
> If I use a linux on top of the qemu, for entering debug mode, do i
> need to compile kernel from source or it is not dependent on debugging
> qemu itself?

I'm not sure I follow. As far as QEMU is concerned it provides a stub
for GDB to talk to and doesn't need to know anything else about the
guest it is running. The GDB itself will want symbols one way or another
so you would either compile your kernel from source or pass the debug
symbol enabled vmlinux to GDB using symbol-file.

> and then is it possible to define a heterogeneous multicore platform
> in qemu?

The current upstream QEMU doesn't support heterogeneous setups although
some preliminary work has been posted to allow multiple front-ends to be
compiled together.

There are certainly out-of-tree solutions although as I understand it
(I've not worked with them myself) they use multiple QEMU runtimes
linked together with some sort of shared memory bus/IPC layer.

> Thanks and regards.
> ________________________________________
> From: Alex Bennée <address@hidden>
> Sent: Thursday, April 28, 2016 6:45 PM
> To: tutu sky
> Cc: Stefan Hajnoczi; address@hidden
> Subject: Re: [Qemu-devel] emulation details of qemu
> tutu sky <address@hidden> writes:
>> Thanks a lot Stefan,
>> But if i want to change the content of a register during run time in
>> debug mode, what should i do? is it possible at first?
> Using the gdbstub sure you can change the register values when the
> machine is halted.
>> Regards.
>> ________________________________________
>> From: Stefan Hajnoczi <address@hidden>
>> Sent: Tuesday, April 26, 2016 9:31 AM
>> To: tutu sky
>> Cc: address@hidden
>> Subject: Re: [Qemu-devel] emulation details of qemu
>> On Sat, Apr 23, 2016 at 06:36:39AM +0000, tutu sky wrote:
>>> I want to know that is it possible to access registers or 
>>> micro-architectural part of a core/cpu in qemu during run time?
>> Yes.  How and to what extent depends on whether you are using TCG, KVM,
>> or TCI.  QEMU also has gdbstub support so you can single-step execution
>> and access CPU registers.
>> Stefan

Alex Bennée

reply via email to

[Prev in Thread] Current Thread [Next in Thread]