From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v2] KVM: VMX: Update instruction length on intercepted BP Date: Tue, 16 Feb 2010 10:11:06 +0100 Message-ID: <4B7A612A.4010603@siemens.com> References: <4B795FD0.4060505@siemens.com> <20100216073352.GV2995@redhat.com> <4B7A51D4.1040701@web.de> <20100216082455.GY2995@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Avi Kivity , Marcelo Tosatti , kvm To: Gleb Natapov Return-path: Received: from thoth.sbs.de ([192.35.17.2]:20239 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755891Ab0BPJLZ (ORCPT ); Tue, 16 Feb 2010 04:11:25 -0500 In-Reply-To: <20100216082455.GY2995@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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