Message-ID: <500E9161.209@suse.de>
Date:	Tue, 24 Jul 2012 14:13:21 +0200
From:	Alexander Graf <agraf@...e.de>
To:	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
Cc:	Rob Landley <rob@...dley.net>, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, Randy Dunlap <rdunlap@...otime.net>,
	KVM <kvm@...r.kernel.org>, "H. Peter Anvin" <hpa@...or.com>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Gleb Natapov <gleb@...hat.com>, Ingo Molnar <mingo@...hat.com>,
	Avi Kivity <avi@...hat.com>,
	Jan Kiszka <jan.kiszka@...mens.com>
Subject: Re: [PATCH] Documentation/kvm : Add documentation on Hypercalls

On 07/24/2012 10:53 AM, Raghavendra K T wrote:
> From: Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
>
> Thanks Alex for KVM_HC_FEATURES inputs and Jan for VAPIC_POLL_IRQ,
> and Peter (HPA) for suggesting hypercall ABI addition.
>
> Signed-off-by: Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
> ---
> Please have a closer look at Hypercall ABI newly added
>
> Changes since last post:
>   - Added hypercall ABI (Peter)
>   - made KVM_HC_VAPIC_POLL_IRQ active explicitly (Randy)
>
> TODO: We need to add history details of each hypercall as suggested by HPA,
> which I could not trace easily. Hope it is easy for hypercall authors
>
>   Documentation/virtual/hypercalls.txt |   71 ++++++++++++++++++++++++++++++++++
>   1 files changed, 71 insertions(+), 0 deletions(-)
>   create mode 100644 Documentation/virtual/hypercalls.txt
>
> diff --git a/Documentation/virtual/hypercalls.txt b/Documentation/virtual/hypercalls.txt
> new file mode 100644
> index 0000000..caffc08
> --- /dev/null
> +++ b/Documentation/virtual/hypercalls.txt
> @@ -0,0 +1,71 @@
> +Hypercall ABI:
> +=============
> +A brief look at calling conventions of X86, S390 and PPC
> +X86:
> + KVM Hypercalls have a three-byte sequence of either the vmrun or the vmmrun
> + instruction. The hypervisor can replace it with instructions that are
> + guaranteed to be supported.
> +
> + Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively.
> + The hypercall number should be placed in rax and the return value will be
> + placed in rax.  No other registers will be clobbered unless explicitly stated
> + by the particular hypercall.
> +
> +S390:
> +  R2-R7 are used for parameters 1-6. In addition, R1 is used for hypercall
> +  number. The return value is written to R2.
> +
> +  S390 uses diagnose instruction as hypercall (0x500) along with hypercall
> +  number in R1.
> +
> + PoewerPC:

PowerPC

> +  It uses R3-R10 and hypercall number in R11. R4-R11 are used as output registers.
> +  Return value is placed in R3.
> +
> +  KVM hypercalls uses 4 byte opcode, that are patched with 'hypercall-instructions'
> +  property inside the device tree's /hypervisor node.
> +  For more information refer to Documentation/virtual/kvm/ppc-pv.txt

What exactly is this document supposed to cover? We have 3 different 
hypercall ABIs in KVM on PowerPC:

   1) KVM hypercalls (ePAPR)

The ePAPR compliant hypercall implementation. This one is used for KVM 
specific hypercalls. All hypercalls get a KVM vendor prefix (42) and 
then the hypercall id. We also implement generic hypercalls here, like 
the ePAPR idle hcall. The instruction sequence for these is listed in 
the device tree, as you noted above. It's available on all targets.

   2) PAPR hypercalls

To run server PowerPC PAPR guests (-M pseries in QEMU), we need to 
handle PAPR hypercalls. These are the same hypercalls that pHyp, the 
POWER hypervisor implements. Some of them are handled in the kernel, 
some are handled in user space. This is only available on book3s_64.

   3) OSI hypercalls

In parallel to QEMU, there is another user of KVM on PowerPC: 
Mac-on-Linux. That project had its own hypercalls long before we came 
along with KVM, so to maintain compatibility we also support their 
hypercalls. All of these get forwarded to user space. This is only 
useful on book3s_32, but can be used with book3s_64 as well.

> +
> +KVM Hypercalls Documentation
> +===========================
> +The template for each hypercall is:
> +1. Hypercall name, value.
> +2. Architecture(s)
> +3. Status (deprecated, obsolete, active)
> +4. Purpose
> +
> +1. KVM_HC_VAPIC_POLL_IRQ
> +------------------------
> +Value: 1

What are the value fields supposed to mean?


Alex

> +Architecture: x86
> +Status: active
> +Purpose: Trigger guest exit so that the host can check for pending
> +interrupts on reentry.
> +
> +2. KVM_HC_MMU_OP
> +------------------------
> +Value: 2
> +Architecture: x86
> +Status: deprecated.
> +Purpose: Support MMU operations such as writing to PTE,
> +flushing TLB, release PT.
> +
> +3. KVM_HC_FEATURES
> +------------------------
> +Value: 3
> +Architecture: PPC
> +Status: active
> +Purpose: Expose hypercall availability to the guest. On x86 platforms, cpuid
> +used to enumerate which hypercalls are available. On PPC, either device tree
> +based lookup ( which is also what EPAPR dictates) OR KVM specific enumeration
> +mechanism (which is this hypercall) can be used.
> +
> +4. KVM_HC_PPC_MAP_MAGIC_PAGE
> +------------------------
> +Value: 4
> +Architecture: PPC
> +Status: active
> +Purpose: To enable communication between the hypervisor and guest there is a
> +shared page that contains parts of supervisor visible register state.
> +The guest can map this shared page to access its supervisor register through
> +memory using this hypercall.
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists