Re: [PATCH v2] KVM: VMX: Update instruction length on intercepted BP

[Jan Kiszka <jan.kiszka@siemens.com>]

Gleb Natapov wrote:
> On Tue, Feb 16, 2010 at 09:05:40AM +0100, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> On Mon, Feb 15, 2010 at 03:53:04PM +0100, Jan Kiszka wrote:
>>>> We intercept #BP while in guest debugging mode. As VM exits due to
>>>> intercepted exceptions do not necessarily come with valid
>>>> idt_vectoring, we have to update event_exit_inst_len explicitly in such
>>>> cases. At least in the absence of migration, this ensures that
>>>> re-injections of #BP will find and use the correct instruction length.
>>>>
>>> Thinking about it some more. Why do we exit to userspace at all if we
>>> intercept wrong #DB? It seams to me not wise to have ability to inject
>>> exceptions from userspace. Exceptions generation mechanism is a part of
>>> CPU and we shouldn't outsource part of CPU functionality to userspace.
>> The guest debugging API was design to avoid maintaining a "countless"
>> number of breakpoints in kernel space and instead chose to loop over
>> user space to decide about #DB & #BP. So this part is required even if
>> we start thinking about an alternative interface in the future.
>>
> How much is "countless"? 10000? I am sure we can handle this.

We could even handle more. But would have to
 - handle INT3 injection in kernel space, including step-over on resume
 - fully parse HW breakpoints in kernel space
 - probably deal with some more complications that are now handled in
   user space, part of them even in gdb

And, again: This is an _existing_ user space ABI. We could only provide
an alternative, but we have to maintain what is there at least for some
longer grace period.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux