On Mon, Nov 24, 2014 at 03:07:35PM +0100, Alexander Graf wrote: > > > On 24.11.14 14:10, Christoffer Dall wrote: > > On Mon, Nov 24, 2014 at 1:56 PM, Alexander Graf <agraf@xxxxxxx> wrote: > >> > >> > >> On 24.11.14 13:53, Christoffer Dall wrote: > >>> On Mon, Nov 24, 2014 at 1:51 PM, Alexander Graf <agraf@xxxxxxx> wrote: > >>>> > >>>> > >>>> On 24.11.14 13:44, Peter Maydell wrote: > >>>>> On 24 November 2014 at 12:41, Alexander Graf <agraf@xxxxxxx> wrote: > >>>>>>> Am 24.11.2014 um 13:32 schrieb Peter Maydell <peter.maydell@xxxxxxxxxx>: > >>>>>>> Yes, but we don't want to know about properties of the guest > >>>>>>> vCPU. In an ideal world QEMU could reserve say half the debug > >>>>>>> registers for debugging the VM on startup and have KVM expose > >>>>>>> ID registers indicating to the guest that it only had the > >>>>>>> other half... > >>>>>> > >>>>>> Yup, so create another (read-only) ONE_REG that exposes the number > >>>>>> of actual guest debug registers. > >>>>> > >>>>> I'm confused. ONE_REG is for guest state, and the ID register > >>>>> by definition is how we tell the guest how many debug registers > >>>>> it has. What we want to know (and perhaps even control) for > >>>>> debugging the VM is how many debug registers the host has. > >>>> > >>>> No, we don't want to know how many debug registers the host has. We want > >>>> to know how many debug registers the guest has. > >>>> > >>>> Imagine you're running on A57 today with 8 debug registers (no idea if > >>>> that's true, but assume it is). Tomorrow there will be a new core - > >>>> let's call it A67 - with 16 debug registers. > >>>> > >>>> To make sure your legacy, badly written guest behaves exactly the same - > >>>> especially after live migration - you want to spawn a VM with -cpu A57. > >>>> That implies you want to expose 8 debug registers into the guest. So > >>>> debug register synchronization should only be aware of those 8 registers. > >>>> > >>>> So what we really care about is the number of debug registers available > >>>> to a guest vcpu. That in turn means it's guest state and as such can > >>>> easily go into ONE_REG. > >>>> > >>> We already export this for the guest via ONE_REG. > >>> > >>> What we want to do is support gdbstubs in QEMU to debug the guest, and > >>> to do this, QEMU needs to know how many hardware registers on the host > >>> there is; the guest will never see this information. > >>> > >>> So this is really about the host, the guest side is trivially handled > >>> through ONE_REG. > >> > >> That's the cp15 register that happens to get exposed to the guest. You > >> can just add another ONE_REG that does not have a cp15 equivalent to > >> expose the number of the vcpu's actually available debug registers. > >> > >> > > The fact that we currently map the guest vcpu registers to that of the > > host doesn't mean that will always be the case (which you argued for > > above). > > > > If you migrate a VM from a CPU with 16 debug registers (or emulate a > > CPU with 16 debug registers) on a physical CPU with only 8 debug > > registers, you cannot tell QEMU that it has 16 debug registers on the > > hardware to configure to debug the guest, which is what ONE_REG would > > give you. > > > > You could add another set of registers to ONE_REG which says "these > > are the host versions", or you could say that you don't ever support a > > setup where the guest number of debug registers is not the same as the > > host number, but both would be wrong. > > Why would QEMU ever want to access debug registers that it didn't ask > for in the first place? If we simply limit ourselves to the register set > the vcpu has we don't have any problems and the complexity matrix > shrinks noticably, no? > (For others following this, not hanging out on #kvm-arm, I provide a summary). We had a lenghty IRC discussion on this, for the curious, go read it here: http://irclogs.linaro.org/2014/11/24/%23kvm-arm.html The point of confusion is that other KVM architectures use the ONE_REG interface to set the debug registers, for both guest and host state, and in fact this can be overlayed. The propose idea of using SET_DEBUGREGS was flawed, because this also pertains to guest state and is a deprecated ABI. So that left us with two choices: (1) Implement a new ABI to retrieve and set host debugging independently of the guest state. (2) Overlay the host debugging of a guest with the guest's internal debugging state (a process inside the guest is debugging a process). Option (1) has the usual drawback of having to design an ABI, consumes the ioctl number space etc. But it also has (the more severe) drawback that debugging the guest using QEMU gdbstubs breaks guest debugging, because we would keep completely distinct register sets. Option (2) feels semantically slightly weird in the cases where the number of guest debug regs differs from the number of host debug regs, but as Alex Graf pointed out, we probably wouldn't dream of supporting more guest debug registers than the host has (refuse migration, don't emulate that VCPU on the PCPU etc.), and we don't care deeply about exposing fewer host debug regs than actually available. Migrating a VM that is being debugged by the host is simply not supported, so any state obtained via ONE_REG for migration is for the guest, not the host. Option (2) has the additional benefit that we can intermix guest and host registers; debug exceptions are in this case always routed to user space and QEMU's magic determines if the exception is for itself or if it should be injected back into the guest. Guest accesses to debug regs are always trapped when the host uses any debug regs, thus not exposing any sensitive state to the guest. Given this information, I personally lean towards approach (2) since it is similar to what is done for other architectures and caters to the most probable use cases that we would care about. Feel free to point out omissions or errors in my reasoning. -Christoffer -- 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
