Interface to enable in-kernel hcall handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux