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

[Gleb Natapov <gleb@redhat.com>]

On Tue, Feb 16, 2010 at 10:11:06AM +0100, Jan Kiszka wrote:
> 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
> 
The first point in this list is needed no anyway, no matter who reinjects
#BP event.  About point three what are those complications? As far as
I see all we need to know in kernel is a list of cr3:address pairs that
have breakpoint set. If #BP intercept happens we scan this list and if
match is not found reinject event to the guest otherwise exit to
userspace.

> 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.
> 
But it was always broken for SVM and was broken for VMX for a year and
nobody noticed, so may be instead of reintroducing old interface we should
do it right this time?

--
			Gleb.