On Mon, Nov 24, 2014 at 1:51 PM, Alexander Graf <ag...@suse.de> wrote: > > > On 24.11.14 13:44, Peter Maydell wrote: >> On 24 November 2014 at 12:41, Alexander Graf <ag...@suse.de> wrote: >>>> Am 24.11.2014 um 13:32 schrieb Peter Maydell <peter.mayd...@linaro.org>: >>>> 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. -Christoffer -- 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
