qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] emulation details of qemu
@ 2016-04-23  6:36 tutu sky
  2016-04-26  9:31 ` Stefan Hajnoczi
  0 siblings, 1 reply; 10+ messages in thread
From: tutu sky @ 2016-04-23  6:36 UTC (permalink / raw)
  To: qemu-devel@nongnu.org

Hi everybody.
I want to know that is it possible to access registers or micro-architectural part of a core/cpu in qemu during run time?
if it is not possible, how we can hotplug a core in this emulator?

thanks a lot.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] emulation details of qemu
  2016-04-23  6:36 [Qemu-devel] emulation details of qemu tutu sky
@ 2016-04-26  9:31 ` Stefan Hajnoczi
  2016-04-28 10:48   ` tutu sky
  0 siblings, 1 reply; 10+ messages in thread
From: Stefan Hajnoczi @ 2016-04-26  9:31 UTC (permalink / raw)
  To: tutu sky; +Cc: qemu-devel@nongnu.org

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] emulation details of qemu
  2016-04-26  9:31 ` Stefan Hajnoczi
@ 2016-04-28 10:48   ` tutu sky
  2016-04-28 18:45     ` Alex Bennée
  0 siblings, 1 reply; 10+ messages in thread
From: tutu sky @ 2016-04-28 10:48 UTC (permalink / raw)
  To: Stefan Hajnoczi; +Cc: qemu-devel@nongnu.org


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?

Regards.
________________________________________
From: Stefan Hajnoczi <stefanha@gmail.com>
Sent: Tuesday, April 26, 2016 9:31 AM
To: tutu sky
Cc: qemu-devel@nongnu.org
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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] emulation details of qemu
  2016-04-28 10:48   ` tutu sky
@ 2016-04-28 18:45     ` Alex Bennée
  2016-04-29 10:56       ` tutu sky
  0 siblings, 1 reply; 10+ messages in thread
From: Alex Bennée @ 2016-04-28 18:45 UTC (permalink / raw)
  To: tutu sky; +Cc: Stefan Hajnoczi, qemu-devel@nongnu.org


tutu sky <ooohooo_u@hotmail.com> 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 <stefanha@gmail.com>
> Sent: Tuesday, April 26, 2016 9:31 AM
> To: tutu sky
> Cc: qemu-devel@nongnu.org
> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] emulation details of qemu
  2016-04-28 18:45     ` Alex Bennée
@ 2016-04-29 10:56       ` tutu sky
  2016-04-29 12:22         ` Alex Bennée
  0 siblings, 1 reply; 10+ messages in thread
From: tutu sky @ 2016-04-29 10:56 UTC (permalink / raw)
  To: Alex Bennée; +Cc: Stefan Hajnoczi, qemu-devel@nongnu.org

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?
and then is it possible to define a heterogeneous multicore platform in qemu?

Thanks and regards. 

________________________________________
From: Alex Bennée <alex.bennee@linaro.org>
Sent: Thursday, April 28, 2016 6:45 PM
To: tutu sky
Cc: Stefan Hajnoczi; qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] emulation details of qemu

tutu sky <ooohooo_u@hotmail.com> 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 <stefanha@gmail.com>
> Sent: Tuesday, April 26, 2016 9:31 AM
> To: tutu sky
> Cc: qemu-devel@nongnu.org
> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] emulation details of qemu
  2016-04-29 10:56       ` tutu sky
@ 2016-04-29 12:22         ` Alex Bennée
  2016-04-29 12:39           ` tutu sky
  0 siblings, 1 reply; 10+ messages in thread
From: Alex Bennée @ 2016-04-29 12:22 UTC (permalink / raw)
  To: tutu sky; +Cc: Stefan Hajnoczi, qemu-devel@nongnu.org


tutu sky <ooohooo_u@hotmail.com> 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 <alex.bennee@linaro.org>
> Sent: Thursday, April 28, 2016 6:45 PM
> To: tutu sky
> Cc: Stefan Hajnoczi; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] emulation details of qemu
>
> tutu sky <ooohooo_u@hotmail.com> 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 <stefanha@gmail.com>
>> Sent: Tuesday, April 26, 2016 9:31 AM
>> To: tutu sky
>> Cc: qemu-devel@nongnu.org
>> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] emulation details of qemu
  2016-04-29 12:22         ` Alex Bennée
@ 2016-04-29 12:39           ` tutu sky
  2016-04-29 15:08             ` Alex Bennée
  0 siblings, 1 reply; 10+ messages in thread
From: tutu sky @ 2016-04-29 12:39 UTC (permalink / raw)
  To: Alex Bennée; +Cc: Stefan Hajnoczi, qemu-devel@nongnu.org

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 <alex.bennee@linaro.org>
Sent: Friday, April 29, 2016 12:22 PM
To: tutu sky
Cc: Stefan Hajnoczi; qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] emulation details of qemu

tutu sky <ooohooo_u@hotmail.com> 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 <alex.bennee@linaro.org>
> Sent: Thursday, April 28, 2016 6:45 PM
> To: tutu sky
> Cc: Stefan Hajnoczi; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] emulation details of qemu
>
> tutu sky <ooohooo_u@hotmail.com> 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 <stefanha@gmail.com>
>> Sent: Tuesday, April 26, 2016 9:31 AM
>> To: tutu sky
>> Cc: qemu-devel@nongnu.org
>> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] emulation details of qemu
  2016-04-29 12:39           ` tutu sky
@ 2016-04-29 15:08             ` Alex Bennée
  2016-04-29 15:24               ` tutu sky
  0 siblings, 1 reply; 10+ messages in thread
From: Alex Bennée @ 2016-04-29 15:08 UTC (permalink / raw)
  To: tutu sky; +Cc: Stefan Hajnoczi, qemu-devel@nongnu.org


tutu sky <ooohooo_u@hotmail.com> writes:

> 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?

I'm not sure I follow. Using the QEMU's gdbstub to debug a guest is
different from debugging QEMU by running it under gdb.

> 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?

Generally to use the stub you start the guest with -s -S, e.g:

qemu-system-arm -machine virt,accel=tcg -cpu cortex-a15 -display none \
  -serial stdio -kernel ./arm/locking-test.flat -smp 4 -s -S

And then invoke gdb with something like:

gdb-multiarch ./arm/locking-test.elf -ex "target remote localhost:1234"

So in this example I'm using the .elf file with gdb as that has the
debugging information for the .flat file I started QEMU with. -ex just
saves the hassle of typing in the "target remote localhost:1234" to
connect to the gdb stub when you start up. Once in gdb you can do all
the usual things:

(gdb) info threads
  Id   Target Id         Frame
  * 1    Thread 1 (CPU#0 [running]) 0x40000000 in ?? ()
    2    Thread 2 (CPU#1 [halted ]) 0x00000000 in ?? ()
    3    Thread 3 (CPU#2 [halted ]) 0x00000000 in ?? ()
    4    Thread 4 (CPU#3 [halted ]) 0x00000000 in ?? ()
(gdb) x/4i $pc
  => 0x40000000:  mov     r0, #0
     0x40000004:  ldr     r1, [pc, #4]    ; 0x40000010
     0x40000008:  ldr     r2, [pc, #4]    ; 0x40000014
     0x4000000c:  ldr     pc, [pc, #4]    ; 0x40000018
(gdb) p/x $r0
$1 = 0x0
(gdb) p/x $r1
$2 = 0x0
(gdb) i
     0x40000004 in ?? ()
  => 0x40000004:  ldr     r1, [pc, #4]    ; 0x40000010
     0x40000008:  ldr     r2, [pc, #4]    ; 0x40000014
     0x4000000c:  ldr     pc, [pc, #4]    ; 0x40000018
(gdb) i
     0x40000008 in ?? ()
  => 0x40000008:  ldr     r2, [pc, #4]    ;
     0x40000014
(gdb) p/x $r1
$3 = 0xffffffff

>
> Thanks and regards.
>
> ________________________________________
> From: Alex Bennée <alex.bennee@linaro.org>
> Sent: Friday, April 29, 2016 12:22 PM
> To: tutu sky
> Cc: Stefan Hajnoczi; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] emulation details of qemu
>
> tutu sky <ooohooo_u@hotmail.com> 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 <alex.bennee@linaro.org>
>> Sent: Thursday, April 28, 2016 6:45 PM
>> To: tutu sky
>> Cc: Stefan Hajnoczi; qemu-devel@nongnu.org
>> Subject: Re: [Qemu-devel] emulation details of qemu
>>
>> tutu sky <ooohooo_u@hotmail.com> 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 <stefanha@gmail.com>
>>> Sent: Tuesday, April 26, 2016 9:31 AM
>>> To: tutu sky
>>> Cc: qemu-devel@nongnu.org
>>> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] emulation details of qemu
  2016-04-29 15:08             ` Alex Bennée
@ 2016-04-29 15:24               ` tutu sky
  2016-04-29 18:26                 ` Alex Bennée
  0 siblings, 1 reply; 10+ messages in thread
From: tutu sky @ 2016-04-29 15:24 UTC (permalink / raw)
  To: Alex Bennée; +Cc: Stefan Hajnoczi, qemu-devel@nongnu.org

Thank you in advance Alex.
you said: "Using the QEMU's gdbstub to debug a guest is different from debugging QEMU by running it under gdb."
if i want to see the hardware's internal which is emulated by QEMU, i must make QEMU to run in step mode and run QEMU under GDB, no matter which guest is running; but if i want to debug a gust, QEMU makes it easy for me by offering "gdbstub" and i may need to compile the kernel from source, Do i understand you right?

________________________________________
From: Alex Bennée <alex.bennee@linaro.org>
Sent: Friday, April 29, 2016 3:08 PM
To: tutu sky
Cc: Stefan Hajnoczi; qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] emulation details of qemu

tutu sky <ooohooo_u@hotmail.com> writes:

> 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?

I'm not sure I follow. Using the QEMU's gdbstub to debug a guest is
different from debugging QEMU by running it under gdb.

> 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?

Generally to use the stub you start the guest with -s -S, e.g:

qemu-system-arm -machine virt,accel=tcg -cpu cortex-a15 -display none \
  -serial stdio -kernel ./arm/locking-test.flat -smp 4 -s -S

And then invoke gdb with something like:

gdb-multiarch ./arm/locking-test.elf -ex "target remote localhost:1234"

So in this example I'm using the .elf file with gdb as that has the
debugging information for the .flat file I started QEMU with. -ex just
saves the hassle of typing in the "target remote localhost:1234" to
connect to the gdb stub when you start up. Once in gdb you can do all
the usual things:

(gdb) info threads
  Id   Target Id         Frame
  * 1    Thread 1 (CPU#0 [running]) 0x40000000 in ?? ()
    2    Thread 2 (CPU#1 [halted ]) 0x00000000 in ?? ()
    3    Thread 3 (CPU#2 [halted ]) 0x00000000 in ?? ()
    4    Thread 4 (CPU#3 [halted ]) 0x00000000 in ?? ()
(gdb) x/4i $pc
  => 0x40000000:  mov     r0, #0
     0x40000004:  ldr     r1, [pc, #4]    ; 0x40000010
     0x40000008:  ldr     r2, [pc, #4]    ; 0x40000014
     0x4000000c:  ldr     pc, [pc, #4]    ; 0x40000018
(gdb) p/x $r0
$1 = 0x0
(gdb) p/x $r1
$2 = 0x0
(gdb) i
     0x40000004 in ?? ()
  => 0x40000004:  ldr     r1, [pc, #4]    ; 0x40000010
     0x40000008:  ldr     r2, [pc, #4]    ; 0x40000014
     0x4000000c:  ldr     pc, [pc, #4]    ; 0x40000018
(gdb) i
     0x40000008 in ?? ()
  => 0x40000008:  ldr     r2, [pc, #4]    ;
     0x40000014
(gdb) p/x $r1
$3 = 0xffffffff

>
> Thanks and regards.
>
> ________________________________________
> From: Alex Bennée <alex.bennee@linaro.org>
> Sent: Friday, April 29, 2016 12:22 PM
> To: tutu sky
> Cc: Stefan Hajnoczi; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] emulation details of qemu
>
> tutu sky <ooohooo_u@hotmail.com> 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 <alex.bennee@linaro.org>
>> Sent: Thursday, April 28, 2016 6:45 PM
>> To: tutu sky
>> Cc: Stefan Hajnoczi; qemu-devel@nongnu.org
>> Subject: Re: [Qemu-devel] emulation details of qemu
>>
>> tutu sky <ooohooo_u@hotmail.com> 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 <stefanha@gmail.com>
>>> Sent: Tuesday, April 26, 2016 9:31 AM
>>> To: tutu sky
>>> Cc: qemu-devel@nongnu.org
>>> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Qemu-devel] emulation details of qemu
  2016-04-29 15:24               ` tutu sky
@ 2016-04-29 18:26                 ` Alex Bennée
  0 siblings, 0 replies; 10+ messages in thread
From: Alex Bennée @ 2016-04-29 18:26 UTC (permalink / raw)
  To: tutu sky; +Cc: Stefan Hajnoczi, qemu-devel@nongnu.org


tutu sky <ooohooo_u@hotmail.com> writes:

> Thank you in advance Alex.
> you said: "Using the QEMU's gdbstub to debug a guest is different from debugging QEMU by running it under gdb."
> if i want to see the hardware's internal which is emulated by QEMU,

If by hardware's internal state then yes, GDB doesn't export much other
than the system registers. However you can extend the gdbstub to make
more machine state visible to gdb. See the gdm-xml directory for
examples of defining additional registers for GDB and the various
target-${foo}/gdbstub.c files which pas those register values back and
forth.


>i must make QEMU to run in step mode and run QEMU under GDB, no matter which guest is running; but if i want to debug a gust, QEMU makes it easy for me by offering "gdbstub" and i may need to compile the kernel from source, Do i understand you right?
>
> ________________________________________
> From: Alex Bennée <alex.bennee@linaro.org>
> Sent: Friday, April 29, 2016 3:08 PM
> To: tutu sky
> Cc: Stefan Hajnoczi; qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] emulation details of qemu
>
> tutu sky <ooohooo_u@hotmail.com> writes:
>
>> 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?
>
> I'm not sure I follow. Using the QEMU's gdbstub to debug a guest is
> different from debugging QEMU by running it under gdb.
>
>> 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?
>
> Generally to use the stub you start the guest with -s -S, e.g:
>
> qemu-system-arm -machine virt,accel=tcg -cpu cortex-a15 -display none \
>   -serial stdio -kernel ./arm/locking-test.flat -smp 4 -s -S
>
> And then invoke gdb with something like:
>
> gdb-multiarch ./arm/locking-test.elf -ex "target remote localhost:1234"
>
> So in this example I'm using the .elf file with gdb as that has the
> debugging information for the .flat file I started QEMU with. -ex just
> saves the hassle of typing in the "target remote localhost:1234" to
> connect to the gdb stub when you start up. Once in gdb you can do all
> the usual things:
>
> (gdb) info threads
>   Id   Target Id         Frame
>   * 1    Thread 1 (CPU#0 [running]) 0x40000000 in ?? ()
>     2    Thread 2 (CPU#1 [halted ]) 0x00000000 in ?? ()
>     3    Thread 3 (CPU#2 [halted ]) 0x00000000 in ?? ()
>     4    Thread 4 (CPU#3 [halted ]) 0x00000000 in ?? ()
> (gdb) x/4i $pc
>   => 0x40000000:  mov     r0, #0
>      0x40000004:  ldr     r1, [pc, #4]    ; 0x40000010
>      0x40000008:  ldr     r2, [pc, #4]    ; 0x40000014
>      0x4000000c:  ldr     pc, [pc, #4]    ; 0x40000018
> (gdb) p/x $r0
> $1 = 0x0
> (gdb) p/x $r1
> $2 = 0x0
> (gdb) i
>      0x40000004 in ?? ()
>   => 0x40000004:  ldr     r1, [pc, #4]    ; 0x40000010
>      0x40000008:  ldr     r2, [pc, #4]    ; 0x40000014
>      0x4000000c:  ldr     pc, [pc, #4]    ; 0x40000018
> (gdb) i
>      0x40000008 in ?? ()
>   => 0x40000008:  ldr     r2, [pc, #4]    ;
>      0x40000014
> (gdb) p/x $r1
> $3 = 0xffffffff
>
>>
>> Thanks and regards.
>>
>> ________________________________________
>> From: Alex Bennée <alex.bennee@linaro.org>
>> Sent: Friday, April 29, 2016 12:22 PM
>> To: tutu sky
>> Cc: Stefan Hajnoczi; qemu-devel@nongnu.org
>> Subject: Re: [Qemu-devel] emulation details of qemu
>>
>> tutu sky <ooohooo_u@hotmail.com> 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 <alex.bennee@linaro.org>
>>> Sent: Thursday, April 28, 2016 6:45 PM
>>> To: tutu sky
>>> Cc: Stefan Hajnoczi; qemu-devel@nongnu.org
>>> Subject: Re: [Qemu-devel] emulation details of qemu
>>>
>>> tutu sky <ooohooo_u@hotmail.com> 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 <stefanha@gmail.com>
>>>> Sent: Tuesday, April 26, 2016 9:31 AM
>>>> To: tutu sky
>>>> Cc: qemu-devel@nongnu.org
>>>> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2016-04-29 18:27 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-23  6:36 [Qemu-devel] emulation details of qemu tutu sky
2016-04-26  9:31 ` Stefan Hajnoczi
2016-04-28 10:48   ` tutu sky
2016-04-28 18:45     ` Alex Bennée
2016-04-29 10:56       ` tutu sky
2016-04-29 12:22         ` Alex Bennée
2016-04-29 12:39           ` tutu sky
2016-04-29 15:08             ` Alex Bennée
2016-04-29 15:24               ` tutu sky
2016-04-29 18:26                 ` Alex Bennée

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).