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. 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
