public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@samba.org>
To: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Interface to enable in-kernel hcall handling
Date: Sat, 16 Nov 2013 19:59:41 +1100	[thread overview]
Message-ID: <20131116085941.GC18339@iris.ozlabs.ibm.com> (raw)

I have been thinking about adding an interface to PPC KVM's PAPR
emulation to allow userspace to control whether or not individual
hypercalls or groups of hypercalls get handled in the kernel
(vs. being passed up to userspace to be handled there).

I can think of a couple of possible interfaces, differing in how the
set of hypercalls to be enabled/disabled is specified.  In each case I
envisage a new VM ioctl which takes an argument specifying which
hypercalls to enable, and possibly another VM ioctl to disable some or
all hypercalls.

One is to use the string defined in PAPR for the group of hypercalls.
This is the string that gets included in the ibm,hypertas-functions
property in the /rtas node of the device tree to indicate to the guest
that the group of hypercalls is available to it, for example,
"hcall-pft" for H_ENTER, H_REMOVE, etc., "hcall-tce" for H_PUT_TCE,
H_GET_TCE and friends, and so on.  This way, userspace can iterate
through the strings in the ibm,hypertas-functions property and call
the enable-hypercall ioctl for each one.

The second is to pass the individual hypercall number and do them one
by one.  The problem with this one is that it may not make sense to
have some of the hypercalls in a related group handled in the kernel
and others in userspace.

The third is to pass a bitmap with one bit per possible hypercall.

Any thoughts/opinions on the relative merits of these ideas?

Paul.

             reply	other threads:[~2013-11-16  8:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-16  8:59 Paul Mackerras [this message]
2013-11-18 21:31 ` Interface to enable in-kernel hcall handling Alexander Graf
2013-11-19  1:02   ` Paul Mackerras
2013-11-19 10:18     ` Alexander Graf

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=20131116085941.GC18339@iris.ozlabs.ibm.com \
    --to=paulus@samba.org \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.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