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? > 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. > The second problem I see is that we're disabling use cases for the sake > of correctness. When I use gdbstub, I usually don't want anything in the > way of debugging something - like if I want to debug the guest debugging > itself for example. I don't have a problem with making it possible for userspace to forcibly claim ownership of the debug registers -- but I don't want to advertise that won't mess up the guest debugging that you're trying to debug, without some reason to believe that. > So overall, I think the x86 approach is a nice middle ground between > usability, performance and functionality. You mean don't document anything other than the mechanism to get/set the registers and hope everything works out? :-) > >>>>> one reg? > >>>> We are using SREGS but if required we can use one_reg. > >>> I thought we were preferring one reg over sregs for new functionality. > >> I'm personally torn on this one. The problem here is that the sregs > >> fields and values are already reserved. For anything we don't have an > >> API for yet, yes, one_reg only. IIUC we have the API here, but were > >> lacking the implementation. > > From a QEMU perspective, are we going to want to update this at the same > > time as everything else, or would jumping through sregs hoops be a > > nuisance? Is the long term goal to have one reg support for everything? > > Because we need to maintain backwards compatibility, I don't think we'll > actually have any benefit from one reg support for everything. We don't need to maintain backwards compatibility with interfaces that were never implemented, and even where we do need to maintain compatibility, that doesn't mean the caller needs to use the old, cumbersome interface (don't assume the caller is QEMU, or that all new features of QEMU need to support old kernels). > 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. -Scott -- 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
