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