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? Alex -- 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
