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.
next prev parent 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).