Re: [Qemu-devel] Re: [PATCH 03/12] Refactor and enhance break/watchpoint API

[Anthony Liguori <anthony@codemonkey.ws>]

Jan Kiszka wrote:
> Jan Kiszka wrote:
>   
>> Anthony Liguori wrote:
>>     
>>> Jan Kiszka wrote:
>>>       
>>>> This patch prepares the QEMU cpu_watchpoint/breakpoint API to allow the
>>>> succeeding enhancements this series comes with.
>>>>
>>>> First of all, it overcomes MAX_BREAKPOINTS/MAX_WATCHPOINTS by switching
>>>> to dynamically allocated data structures that are kept in linked lists.
>>>> This also allows to return a stable reference to the related objects,
>>>> required for later introduced x86 debug register support.
>>>>
>>>> Breakpoints and watchpoints are stored with their full information set
>>>> and an additional flag field that makes them easily extensible for use
>>>> beyond pure guest debugging.
>>>>
>>>> Finally, this restructuring lays the foundation for KVM to hook into
>>>> the debugging infrastructure, providing its own services where hardware
>>>> virtualization demands it. Once QEMUAccel is considered for merge,
>>>> those entry point should be included into its abstraction layer so that
>>>> accellerators can hook in even more cleanly.
>>>>   
>>>>         
>>> We've merged KVM support (although not QEMUAccel), so perhaps you can
>>> also add the KVM hooks in this series that you are thinking of?
>>>       
>> I will check how much of my kvm patches for guest debugging can already
>> be ported over.
>>
>> That topic is more complex - if you recall my according series - as kvm
>> requires kernel changes to gain full guest debugging support. I'm not
>> even sure if it makes sense to add support for the current kernel
>> interface as it is too restricted (no watchpoints, only 4 breakpoints).
>> However, will re-check if some patch re-ordering may help the migration.
>>
>>     
>
> I had a closer look meanwhile. Given the fact that there are no kvm bits
> for supporting guest debugging in qemu yet and that it would take some
> additional effort for me to establish this for the old interface, I
> would like to skip this step and suggest a different roadmap instead:
>
>  o integrate plain qemu bits for full guest debugging (this series)
>  o wait for Avi to merge them into kvm-userspace
>  o rebase my kvm guest debugging series over kvm-userspace
>    (kernel bits are already up to date) and submit it for review/merge
>  o port stabilized kvm guest debugging over to qemu, but demanding the
>    new kernel ABI
>   

Yeah, that's fine.

Regards,

ANthony Liguori

> OK? Time is a scarce resource, so I would really like to omit
> stabilizing a feature based on an outdated interface to a still too
> young (for daily use, including guest debugging) kvm support of qemu.
>
> Jan
>
>