Gleb Natapov wrote: > 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 :) Yes, a good reason to implement yet another one. :) > 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. Event injection is well supported by both vendors (except for those software-triggered events). Just because QEMU mostly uses it for reset and migration doesn't mean we have to restrict other users to only those cases as well. And as we have true event injection now, and as it naturally conflicts with the special KVM_SET_GUEST_DEBUG interface, I have a patch that consolidates this usage for QEMU: use the old interface of SET_GUEST_DEBUG for pre-2.6.33 kernels, switch to SET_VCPU_EVENTS on recent ones. 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
