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 -- 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
