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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
