qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cornelia.huck@de.ibm.com>
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>
Subject: Re: [Qemu-devel] [PATCH 1/2] s390: Add a hypercall registration interface.
Date: Wed, 16 Jan 2013 13:51:37 +0100	[thread overview]
Message-ID: <20130116135137.7fd57772@gondolin> (raw)
In-Reply-To: <D7ADAFF7-37C9-44F9-9CC9-21C9F6905325@suse.de>

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.

  reply	other threads:[~2013-01-16 12:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-16 11:57 [Qemu-devel] [PATCH 0/2] s390-virtio: Some cleanups Cornelia Huck
2013-01-16 11:57 ` [Qemu-devel] [PATCH 1/2] s390: Add a hypercall registration interface Cornelia Huck
2013-01-16 12:17   ` Alexander Graf
2013-01-16 12:51     ` Cornelia Huck [this message]
2013-01-16 11:57 ` [Qemu-devel] [PATCH 2/2] s390-virtio: Factor out some initialization code Cornelia Huck
2013-01-16 12:19   ` Alexander Graf
2013-01-16 12:41   ` Andreas Färber
2013-01-16 13:05     ` Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130116135137.7fd57772@gondolin \
    --to=cornelia.huck@de.ibm.com \
    --cc=agraf@suse.de \
    --cc=borntraeger@de.ibm.com \
    --cc=jfrei@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).