On Tue, 2014-07-01 at 18:22 +0200, Alexander Graf wrote: > On 01.07.14 17:35, Scott Wood wrote: > > On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote: > >> On 01.07.14 16:58, Scott Wood wrote: > >>> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote: > >>>> I don't think QEMU should be aware of these limitations. > >>> OK, but we should at least have some idea of how the whole thing is > >>> supposed to work, in order to determine if this is the correct behavior > >>> for QEMU. I thought the model was that debug resources are either owned > >>> by QEMU or by the guest, and in the latter case, QEMU would never see > >>> the debug exception to begin with. > >> That's bad for a number of reasons. For starters it's different from how > >> x86 handles debug registers - and I hate to be different just for the > >> sake of being different. > > How does it work on x86? > > It overwrites more-or-less random breakpoints with its own ones, but > leaves the others intact ;).
Are you talking about software breakpoints or management of hardware debug registers? > >> So if we do want to declare that debug registers are owned by either > >> QEMU or the guest, we should change the semantics for all > >> architectures. > > If we want to say that ownership of the registers is shared, we need a > > plan for how that would actually work. > > I think you're overengineering here :). When do people actually use > gdbstub? Usually when they want to debug a broken guest. We can either > > * overengineer heavily and reduce the number of registers available > to the guest to always have spares > * overengineer a bit and turn off guest debugging completely when we > use gdbstub > * just leave as much alive as we can, hoping that it helps with the > debugging > > Option 3 is what x86 does - and I think it's a reasonable approach. This > is not an interface that needs to be 100% consistent and bullet proof, > it's a best effort to enable you to debug as much as possible. I'm not insisting on 100% -- just hoping for some explanation/discussion about how it's intended to work for the cases where it can. How will MSR[DE] and MSRP[DEP] be handled? How would I go about telling QEMU/KVM that I don't want this shared mode, because I don't want guest to interfere with the debugging I'm trying to do from QEMU? Will guest accesses to debug registers cause a userspace exit when guest_debug is enabled? > >> I think we're in a path that is slow enough already to not worry about > >> performance. > > It's not just about performance, but simplicity of use, and consistency > > of API. > > > > Oh, and it looks like there already exist one reg definitions and > > implementations for most of the debug registers. > > For BookE? Where? arch/powerpc/kvm/booke.c: KVM_REG_PPC_IACn, KVM_REG_PPC_DACn -Scott -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
