On 11/10/2011 05:05 PM, Marcelo Tosatti wrote:
On Mon, Oct 31, 2011 at 08:53:11AM +0100, 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.

Signed-off-by: Alexander Graf<ag...@suse.de>
---
  Documentation/virtual/kvm/api.txt |   47 ++++++++++++++++++++++++++++++++++
  arch/powerpc/kvm/powerpc.c        |   51 +++++++++++++++++++++++++++++++++++++
  include/linux/kvm.h               |   32 +++++++++++++++++++++++
  3 files changed, 130 insertions(+), 0 deletions(-)
I don't see the benefit of this generalization, the current structure where
context information is hardcoded in the data transmitted works well.

Well, unfortunately it doesn't work quite as well for us because we are a much more evolving platform. Also, there are a lot of edges and corners of the architecture that simply aren't implemented in KVM as of now. I want to have something extensible enough so we don't break the ABI along the way.


Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to