On 01/05/2012 10:15 PM, Alexander Graf wrote: > Right now we transfer a static struct every time we want to get or set > registers. Unfortunately, over time we realize that there are more of > these than we thought of before and the extensibility and flexibility of > transferring a full struct every time is limited. > > So this is a new approach to the problem. With these new ioctls, we can > get and set a single register that is identified by an ID. This allows for > very precise and limited transmittal of data. When we later realize that > it's a better idea to shove over multiple registers at once, we can reuse > most of the infrastructure and simply implement a GET_MANY_REGS / SET_MANY_REGS > interface. > > The only downpoint I see to this one is that it needs to pad to 1024 bits > (hardware is already on 512 bit registers, so I wanted to leave some room) > which is slightly too much for transmitting only 64 bits. But if that's all > the tradeoff we have to do for getting an extensible interface, I'd say go > for it nevertheless. The comment about padding is no longer relevant. > +/* > + * Architecture specific registers are to be defined in arch headers and > + * ORed with the arch identifier. > + */ > +#define KVM_REG_PPC 0x1000000000000000ULL > +#define KVM_REG_X86 0x2000000000000000ULL > +#define KVM_REG_IA64 0x3000000000000000ULL > +#define KVM_REG_ARM 0x4000000000000000ULL > +#define KVM_REG_S390 0x5000000000000000ULL > + > +#define KVM_REG_SIZE_SHIFT 52 > +#define KVM_REG_SIZE_MASK 0x00f0000000000000ULL > +#define KVM_REG_SIZE_U8 0x0000000000000000ULL > +#define KVM_REG_SIZE_U16 0x0010000000000000ULL > +#define KVM_REG_SIZE_U32 0x0020000000000000ULL > +#define KVM_REG_SIZE_U64 0x0030000000000000ULL > +#define KVM_REG_SIZE_U128 0x0040000000000000ULL > +#define KVM_REG_SIZE_U256 0x0050000000000000ULL > +#define KVM_REG_SIZE_U512 0x0060000000000000ULL > +#define KVM_REG_SIZE_U1024 0x0070000000000000ULL Why not just encode directly as number of bytes? -Scott -- 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
