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 15:12:38 +0200 Message-ID: <20100217131238.GV2995@redhat.com> References: <4B795FD0.4060505@siemens.com> <20100216073352.GV2995@redhat.com> <4B7A51D4.1040701@web.de> <20100216082455.GY2995@redhat.com> <4B7A612A.4010603@siemens.com> <20100217104304.GP2995@redhat.com> <4B7BCF59.40402@redhat.com> <20100217111641.GS2995@redhat.com> <4B7BD1BB.7090909@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]:50896 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751215Ab0BQNMn (ORCPT ); Wed, 17 Feb 2010 08:12:43 -0500 Content-Disposition: inline In-Reply-To: <4B7BD1BB.7090909@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Feb 17, 2010 at 12:23:39PM +0100, Jan Kiszka wrote: > Gleb Natapov wrote: > > On Wed, Feb 17, 2010 at 01:13:29PM +0200, Avi Kivity wrote: > >> On 02/17/2010 12:43 PM, Gleb Natapov wrote: > >>>> 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? > >> We need to fix the existing interface first, and then think long and > >> hard if we want yet another interface, since we're likely to screw > >> it up as well. > >> > >> The more interfaces we introduce, the harder maintenance becomes. > >> > > We are in a sad state if we cannot improve interface. The current one > > outsource part of CPU functionality into userspace. This should be a big > > no-no. > > I still disagree on this. Moving the decision logic to user space > prevented to re-implement a gdbstub in kernel space. I oversaw that > re-injecting #BP over older SVM was broken, but it is now fixed for all > vendors. So moving it back to kernel has actually no long-term reason. > There were patches to implement gdbstub in kernel space! And not so long time ago :) But I want to move only a tiny bit of logic into the kernel space. And #BP reinjection brokenness is a different issue. It should be fixed anyway no matter where decision about reinfection happens. If maintainers think that we should not have improved interface and we should support reinjection of #DB from userspace then this patch should be applied. I don't have other objections to it. But I, at least, would prefer the old interface for #DB reinjection (KVM_GUESTDBG_INJECT_DB) and not the new one. The old one makes it explicit what we are doing, the new one allows injection of any event and should be used only during migration or CPU reset. It would be event good idea to fail setting events if CPU is running. -- Gleb.