From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH v2] KVM: VMX: Update instruction length on intercepted BP Date: Wed, 17 Feb 2010 12:43:04 +0200 Message-ID: <20100217104304.GP2995@redhat.com> References: <4B795FD0.4060505@siemens.com> <20100216073352.GV2995@redhat.com> <4B7A51D4.1040701@web.de> <20100216082455.GY2995@redhat.com> <4B7A612A.4010603@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Marcelo Tosatti , kvm To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:11116 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752721Ab0BQKnH (ORCPT ); Wed, 17 Feb 2010 05:43:07 -0500 Content-Disposition: inline In-Reply-To: <4B7A612A.4010603@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.