On 19.09.2012, at 05:37, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 2012-09-14 at 03:44 +0200, Alexander Graf wrote: >> >> We're slowly moving towards ONE_REG. ARM is already going full steam >> ahead and I'd like to have every new register in PPC be modeled with >> it as well. The old interface broke on us one time too often now :). >> >> As I said, if we run into performance problems, we will implement ways >> to improve performance. At the end of the day, x86 will be the odd one >> out. > > This is totally insane. In most cases, we care about the whole set of 32 > registers. Doing 32 ioctl's for that is just plain stupid. No. In most cases we care about ~100 registers that we want to synchronize. Doing 10 ioctls for that is insane. I want to move to a model where we can have only a single ioctl for all of the 100 regs. But the first step towards that direction is to split them into individual ioctls with explicit IDs for each, so we can then introduce sn ioctl that can write an arbitrary number of regs. The ioctl to read/write an array of registers is dead simple. Just ask Rusty - he already has a prototype in a branch :). Also, don't only think about QEMU here. If you want to write a different user space for KVM, you might not want to keep a copy of the guest CPU's state in some struct. Instead, you could on every register access from user space simply call the one_reg API and leave all stare to kvm. Either way, we only synchronize these registers quite seldomly. We do it when you check out registers on the monitor, when we live migrate, or when we have some odd hypercall that requires knowledge of more guest state than it should (vmport). But this really is not a fast path today. Alex > > There is nothing wrong in allowing the "one reg" interface as well, but > it's totally ridiculous to *require* it. > > Ben. > > -- 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
