From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] spapr: Add "memop" hypercall Date: Mon, 21 May 2012 13:07:27 +0300 Message-ID: <4FBA13DF.7040009@redhat.com> References: <1337585042.2779.4.camel@pasglop> <4FBA0F23.5040601@redhat.com> <1337594641.2779.59.camel@pasglop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexander Graf , kvm@vger.kernel.org, kvm-ppc To: Benjamin Herrenschmidt Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37543 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754501Ab2EUKgH (ORCPT ); Mon, 21 May 2012 06:36:07 -0400 In-Reply-To: <1337594641.2779.59.camel@pasglop> Sender: kvm-owner@vger.kernel.org List-ID: On 05/21/2012 01:04 PM, Benjamin Herrenschmidt wrote: > On Mon, 2012-05-21 at 12:47 +0300, Avi Kivity wrote: > > On 05/21/2012 10:24 AM, Benjamin Herrenschmidt wrote: > > > This adds a kvm-specific hypervisor call to the pseries machine > > > which allows to do what amounts to memmove, memcpy and xor over > > > regions of physical memory such as the framebuffer. > > > > > > This is the simplest way to get usable framebuffer speed from > > > SLOF since the framebuffer isn't mapped in the VRMA and so would > > > otherwise require an hcall per 8 bytes access. > > > > > > The performance is still not great but usable, and can be improved > > > with a more complex implementation of the hcall itself if needed. > > > > > > Signed-off-by: Benjamin Herrenschmidt > > > --- > > > hw/spapr.h | 3 ++- > > > hw/spapr_hcall.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ > > > 2 files changed, 51 insertions(+), 1 deletion(-) > > > > > > > Shouldn't these be documented somewhere? > > Hrm, that's a good point. So far we've been mostly implementing the PAPR > spec so the documentation exists. > > Before that patch we only had one "special" hcall not in PAPR, which we > use for the RTAS firmware calls (this part of the FW normally lives > inside the guest on real pHyp and communicates with the hypervisor using > private hcalls, on qemu, we just turn all the RTAS calls to qemu via a > single H_RTAS multiplexer). We haven't documented it. > > Now I'm adding another one, so yes, it's looking like a trend :-) I'll > look into it, at this stage with only those two, adding some comments in > the header might be plenty enough. Documentation/virtual/kvm/ppc-pv.txt is a nice central place for these. It would be even better if you could add them to the spec. -- error compiling committee.c: too many arguments to function