From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH 09/14] KVM: PPC: Add generic single register ioctls Date: Thu, 10 Nov 2011 17:49:42 +0100 Message-ID: <4EBC00A6.6040803@suse.de> References: <1320047596-20577-1-git-send-email-agraf@suse.de> <1320047596-20577-10-git-send-email-agraf@suse.de> <20111110160536.GD7554@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-ppc@vger.kernel.org, kvm list To: Marcelo Tosatti Return-path: In-Reply-To: <20111110160536.GD7554@amt.cnet> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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 >> --- >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Thu, 10 Nov 2011 16:49:42 +0000 Subject: Re: [PATCH 09/14] KVM: PPC: Add generic single register ioctls Message-Id: <4EBC00A6.6040803@suse.de> List-Id: References: <1320047596-20577-1-git-send-email-agraf@suse.de> <1320047596-20577-10-git-send-email-agraf@suse.de> <20111110160536.GD7554@amt.cnet> In-Reply-To: <20111110160536.GD7554@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Marcelo Tosatti Cc: kvm-ppc@vger.kernel.org, kvm list 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 >> --- >> 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