From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:41321)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cornelia.huck@de.ibm.com>) id 1TvST9-0006qn-LP
	for qemu-devel@nongnu.org; Wed, 16 Jan 2013 07:51:52 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <cornelia.huck@de.ibm.com>) id 1TvST7-0008NV-Vb
	for qemu-devel@nongnu.org; Wed, 16 Jan 2013 07:51:51 -0500
Received: from e06smtp10.uk.ibm.com ([195.75.94.106]:43919)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cornelia.huck@de.ibm.com>) id 1TvST7-0008Me-MJ
	for qemu-devel@nongnu.org; Wed, 16 Jan 2013 07:51:49 -0500
Received: from /spool/local
	by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <qemu-devel@nongnu.org> from <cornelia.huck@de.ibm.com>;
	Wed, 16 Jan 2013 12:51:15 -0000
Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com
	[9.149.37.248])
	by b06cxnps3075.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with
	ESMTP id r0GCpZ6364946212
	for <qemu-devel@nongnu.org>; Wed, 16 Jan 2013 12:51:35 GMT
Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com
	[127.0.0.1])
	by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with
	ESMTP id r0GBtUjP016855
	for <qemu-devel@nongnu.org>; Wed, 16 Jan 2013 06:55:30 -0500
Date: Wed, 16 Jan 2013 13:51:37 +0100
From: Cornelia Huck <cornelia.huck@de.ibm.com>
Message-ID: <20130116135137.7fd57772@gondolin>
In-Reply-To: <D7ADAFF7-37C9-44F9-9CC9-21C9F6905325@suse.de>
References: <1358337445-53555-1-git-send-email-cornelia.huck@de.ibm.com>
	<1358337445-53555-2-git-send-email-cornelia.huck@de.ibm.com>
	<D7ADAFF7-37C9-44F9-9CC9-21C9F6905325@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 1/2] s390: Add a hypercall registration
	interface.
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>, Jens Freimann <jfrei@linux.vnet.ibm.com>, qemu-devel <qemu-devel@nongnu.org>

On Wed, 16 Jan 2013 13:17:34 +0100
Alexander Graf <agraf@suse.de> wrote:

> 
> On 16.01.2013, at 12:57, Cornelia Huck wrote:
> 
> > Allow virtio machines to register for different diag500 function
> > codes and convert s390-virtio to use it.
> > 
> > Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> 
> Nice cleanup :). One minor nitpick below

> > +int s390_virtio_hypercall(CPUS390XState *env)
> > +{
> > +    s390_virtio_fn fn = s390_diag500_table[env->regs[1]];
> > +
> > +    return fn ? fn(env->regs[2], env->regs[3], env->regs[4], env->regs[5],
> > +                   env->regs[6], env->regs[7]) : -EINVAL;
> 
> if (!fn) {
>     return -EINVAL;
> }
> 
> return fn(&env->regs[2]);
> 
> That way the hypercall handling function can determine itself which registers it really needs to access.

Yes, this looks a bit nicer. v2 is on the way.

> 
> 
> > +}

> > static int handle_hypercall(CPUS390XState *env, struct kvm_run *run)
> > {
> >     cpu_synchronize_state(env);
> > -    env->regs[2] = s390_virtio_hypercall(env, env->regs[2], env->regs[1]);
> > +    env->regs[2] = s390_virtio_hypercall(env);
> 
> Just thinking out loud here. With synchronized registers, we have full access to the GPRs already without copying them to env. So if instead we would call
> 
>     s390_virtio_hypercall(env->regs);
> 
> we could in case we support synchronized registers call
> 
>     s390_virtio_hypercall(kvm_run->s.regs.gprs);
> 
> which would completely remove the need for cpu_synchronize_state() for normal hypercalls.
> 
> This is outside of the scope of this patch, but might be a useful thing to do :). As a nice side effect, the global s390_virtio_hypercall function wouldn't have to know anything about CPUState either.

Sounds like a good future improvement.