* [PATCH] [RFC] Fix for kvm qemu to return control to gdb stub on breakpoints
@ 2008-05-22 16:21 Jerone Young
2008-05-22 16:43 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: Jerone Young @ 2008-05-22 16:21 UTC (permalink / raw)
To: kvm
1 file changed, 2 insertions(+)
qemu/qemu-kvm.c | 2 ++
Currently breakpoints do not fully work for x86 or any other arch with kvm enable qemu. Control is not being returned by to the gdb stub. This patch add back this ability to return control to the gdb stub when a debug interrupt is hit.
This is in the io thread so it's best to get comments on this. Is it in the best place? Should more be done here?
Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -352,6 +352,8 @@ static int kvm_main_loop_cpu(CPUState *e
update_regs_for_init(env);
if (!(env->hflags & HF_HALTED_MASK) && !info->init)
kvm_cpu_exec(env);
+ if (env->exception_index == EXCP_DEBUG)
+ vm_stop(EXCP_DEBUG);
env->interrupt_request &= ~CPU_INTERRUPT_EXIT;
kvm_main_loop_wait(env, 0);
if (info->reload_regs) {
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] [RFC] Fix for kvm qemu to return control to gdb stub on breakpoints
2008-05-22 16:21 [PATCH] [RFC] Fix for kvm qemu to return control to gdb stub on breakpoints Jerone Young
@ 2008-05-22 16:43 ` Jan Kiszka
2008-05-22 18:00 ` Anthony Liguori
2008-05-22 18:10 ` Jerone Young
0 siblings, 2 replies; 6+ messages in thread
From: Jan Kiszka @ 2008-05-22 16:43 UTC (permalink / raw)
To: Jerone Young; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]
Jerone Young wrote:
> 1 file changed, 2 insertions(+)
> qemu/qemu-kvm.c | 2 ++
>
>
> Currently breakpoints do not fully work for x86 or any other arch with kvm enable qemu. Control is not being returned by to the gdb stub. This patch add back this ability to return control to the gdb stub when a debug interrupt is hit.
>
> This is in the io thread so it's best to get comments on this. Is it in the best place? Should more be done here?
>
> Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
>
> diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
> --- a/qemu/qemu-kvm.c
> +++ b/qemu/qemu-kvm.c
> @@ -352,6 +352,8 @@ static int kvm_main_loop_cpu(CPUState *e
> update_regs_for_init(env);
> if (!(env->hflags & HF_HALTED_MASK) && !info->init)
> kvm_cpu_exec(env);
> + if (env->exception_index == EXCP_DEBUG)
> + vm_stop(EXCP_DEBUG);
This isn't enough, please see
http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/17660
and the rest of that series - just RFC, but already usable.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] [RFC] Fix for kvm qemu to return control to gdb stub on breakpoints
2008-05-22 16:43 ` Jan Kiszka
@ 2008-05-22 18:00 ` Anthony Liguori
2008-05-22 19:04 ` Jan Kiszka
2008-05-22 18:10 ` Jerone Young
1 sibling, 1 reply; 6+ messages in thread
From: Anthony Liguori @ 2008-05-22 18:00 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Jerone Young, kvm
Jan Kiszka wrote:
> Jerone Young wrote:
>
>> 1 file changed, 2 insertions(+)
>> qemu/qemu-kvm.c | 2 ++
>>
>>
>> Currently breakpoints do not fully work for x86 or any other arch with kvm enable qemu. Control is not being returned by to the gdb stub. This patch add back this ability to return control to the gdb stub when a debug interrupt is hit.
>>
>> This is in the io thread so it's best to get comments on this. Is it in the best place? Should more be done here?
>>
>> Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
>>
>> diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
>> --- a/qemu/qemu-kvm.c
>> +++ b/qemu/qemu-kvm.c
>> @@ -352,6 +352,8 @@ static int kvm_main_loop_cpu(CPUState *e
>> update_regs_for_init(env);
>> if (!(env->hflags & HF_HALTED_MASK) && !info->init)
>> kvm_cpu_exec(env);
>> + if (env->exception_index == EXCP_DEBUG)
>> + vm_stop(EXCP_DEBUG);
>>
>
> This isn't enough, please see
>
> http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/17660
>
> and the rest of that series - just RFC, but already usable.
>
While I haven't looked through your whole series, the io-thread caused a
regression with gdb and while I don't think that this patch is enough of
a fix, it's certainly the right idea for fixing that regression.
Soft breakpoints is a nice thing to do, but I think orthogonal to what
this patch is addressing.
Regards,
Anthony Liguori
> Jan
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] [RFC] Fix for kvm qemu to return control to gdb stub on breakpoints
2008-05-22 18:00 ` Anthony Liguori
@ 2008-05-22 19:04 ` Jan Kiszka
0 siblings, 0 replies; 6+ messages in thread
From: Jan Kiszka @ 2008-05-22 19:04 UTC (permalink / raw)
To: Anthony Liguori; +Cc: Jerone Young, kvm
[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]
Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Jerone Young wrote:
>>
>>> 1 file changed, 2 insertions(+)
>>> qemu/qemu-kvm.c | 2 ++
>>>
>>>
>>> Currently breakpoints do not fully work for x86 or any other arch
>>> with kvm enable qemu. Control is not being returned by to the gdb
>>> stub. This patch add back this ability to return control to the gdb
>>> stub when a debug interrupt is hit.
>>>
>>> This is in the io thread so it's best to get comments on this. Is it
>>> in the best place? Should more be done here?
>>>
>>> Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
>>>
>>> diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
>>> --- a/qemu/qemu-kvm.c
>>> +++ b/qemu/qemu-kvm.c
>>> @@ -352,6 +352,8 @@ static int kvm_main_loop_cpu(CPUState *e
>>> update_regs_for_init(env);
>>> if (!(env->hflags & HF_HALTED_MASK) && !info->init)
>>> kvm_cpu_exec(env);
>>> + if (env->exception_index == EXCP_DEBUG)
>>> + vm_stop(EXCP_DEBUG);
>>>
>>
>> This isn't enough, please see
>>
>> http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/17660
>>
>> and the rest of that series - just RFC, but already usable.
>>
>
> While I haven't looked through your whole series, the io-thread caused a
> regression with gdb and while I don't think that this patch is enough of
> a fix, it's certainly the right idea for fixing that regression.
>
> Soft breakpoints is a nice thing to do, but I think orthogonal to what
> this patch is addressing.
For sure this or a similar approach is required, and I'm fine if we fix
this beforehand. I just pointed to my series to avoid duplicate and
lengthy debugging of known and (hopefully) fixed issues. I already went
through this. :)
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] [RFC] Fix for kvm qemu to return control to gdb stub on breakpoints
2008-05-22 16:43 ` Jan Kiszka
2008-05-22 18:00 ` Anthony Liguori
@ 2008-05-22 18:10 ` Jerone Young
2008-05-22 19:04 ` Jan Kiszka
1 sibling, 1 reply; 6+ messages in thread
From: Jerone Young @ 2008-05-22 18:10 UTC (permalink / raw)
To: Jan Kiszka; +Cc: kvm
This is mainly to try and fix the current debug state with using
hardware breakpoints (until your software breakpoint work is ready for
primetime). I actually do need to submit another patch outside of this
for initialization of some variables (which I see is in your patch too),
as it ends up passing down garbage.
For now this is a patch mainly just to get qemu to break into the gdb
stub when a debug interrupt comes in. Though I have a feeling more may
be needed.
On Thu, 2008-05-22 at 18:43 +0200, Jan Kiszka wrote:
> Jerone Young wrote:
> > 1 file changed, 2 insertions(+)
> > qemu/qemu-kvm.c | 2 ++
> >
> >
> > Currently breakpoints do not fully work for x86 or any other arch with kvm enable qemu. Control is not being returned by to the gdb stub. This patch add back this ability to return control to the gdb stub when a debug interrupt is hit.
> >
> > This is in the io thread so it's best to get comments on this. Is it in the best place? Should more be done here?
> >
> > Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
> >
> > diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
> > --- a/qemu/qemu-kvm.c
> > +++ b/qemu/qemu-kvm.c
> > @@ -352,6 +352,8 @@ static int kvm_main_loop_cpu(CPUState *e
> > update_regs_for_init(env);
> > if (!(env->hflags & HF_HALTED_MASK) && !info->init)
> > kvm_cpu_exec(env);
> > + if (env->exception_index == EXCP_DEBUG)
> > + vm_stop(EXCP_DEBUG);
>
> This isn't enough, please see
>
> http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/17660
>
> and the rest of that series - just RFC, but already usable.
>
> Jan
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] [RFC] Fix for kvm qemu to return control to gdb stub on breakpoints
2008-05-22 18:10 ` Jerone Young
@ 2008-05-22 19:04 ` Jan Kiszka
0 siblings, 0 replies; 6+ messages in thread
From: Jan Kiszka @ 2008-05-22 19:04 UTC (permalink / raw)
To: jyoung5; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]
Jerone Young wrote:
> This is mainly to try and fix the current debug state with using
> hardware breakpoints (until your software breakpoint work is ready for
Well, you may be lucky with hw-breakpoints on Intel, given userland is
patched. But if you aren't (IIRC, current code leaks debug register
settings outside the guest, e.g.), I wouldn't invest time here. The
debug register handling requires a rewrite in order to support proper
virtualization + guest debugging.
Right now I'm trying the clean up my debug patches and get things out:
1. Reworked guest debug interface
2. Fixed and enhanced userland support (including soft-BPs)
3. debug register virtualization
4. guest debugging with hw-breakpoints/watchpoints
I hope step 1 & 2 can be completed tonight, 3 & 4 finally over the weekend.
> primetime). I actually do need to submit another patch outside of this
> for initialization of some variables (which I see is in your patch too),
> as it ends up passing down garbage.
Yeah, that was another issue.
>
> For now this is a patch mainly just to get qemu to break into the gdb
> stub when a debug interrupt comes in. Though I have a feeling more may
> be needed.
If you want to fix userland, you also have to ensure that the vcpu
thread that received the breakpoint doesn't continue to run - see my patch.
That said, if you have spare cycles left to spent on the debugging
thing, I would try to re-schedule my work and push some packages over to
your side. Just let me know! :)
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-05-22 19:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-22 16:21 [PATCH] [RFC] Fix for kvm qemu to return control to gdb stub on breakpoints Jerone Young
2008-05-22 16:43 ` Jan Kiszka
2008-05-22 18:00 ` Anthony Liguori
2008-05-22 19:04 ` Jan Kiszka
2008-05-22 18:10 ` Jerone Young
2008-05-22 19:04 ` Jan Kiszka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox