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