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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
