https://linux-kvm.org/api.php?action=feedcontributions&user=AF&feedformat=atomKVM - User contributions [en]2024-03-29T10:34:04ZUser contributionsMediaWiki 1.39.5https://linux-kvm.org/index.php?title=KVM_Forum_2014_BOF&diff=23041KVM Forum 2014 BOF2014-09-18T11:37:39Z<p>AF: Added myself</p>
<hr />
<div>= Introduction =<br />
<br />
We will reserve some time for people to get together and discuss<br />
strategic decisions as well as other topics that are best solved within<br />
smaller groups. This time can also be used for hands-on hacking<br />
sessions.<br />
<br />
If you are interested in organizing such a group time event, please add<br />
it to the list *before* KVM Forum, so people have time to organize which<br />
one they will attend.<br />
<br />
All of these sessions will get the chance to quickly talk about results<br />
they managed to achieve during their time in a quick "results" session.<br />
<br />
= BoF Ideas =<br />
<br />
== OVMF ==<br />
<br />
=== Open Virtual Machine Firmware ===<br />
<br />
'''Summary:''' OVMF (Open Virtual Machine Firmware) is a project to enable<br />
UEFI support for Virtual Machines. This BoF should allow users and<br />
developers of virtualization and/or UEFI software to discuss how OVMF fits<br />
in the "intersection" of virt and UEFI, what it is good for, how it can be<br />
used, how people can contribute, and how OVMF works, internally and in<br />
combination with the other layers of the virt stack.<br />
<br />
The Unified Extensible Firmware Interface (UEFI) is a specification that<br />
defines a software interface between an operating system and platform<br />
firmware. UEFI is designed to replace the Basic Input/Output System (BIOS)<br />
firmware interface.<br />
<br />
Hardware platform vendors have been increasingly adopting the UEFI<br />
Specification to govern their boot firmware developments. OVMF (Open Virtual<br />
Machine Firmware), a sub-project of Intel's EFI Development Kit II (edk2),<br />
enables UEFI support for Ia32 and X64 Virtual Machines.<br />
<br />
In this BoF all areas and topics related to the overlap of virt and UEFI are<br />
welcome (regardless of their "technical depth"), except politics and/or<br />
historical controversy around UEFI Secure Boot. (Discussing Secure Boot per<br />
se is fine.)<br />
<br />
'''People:'''<br />
* Laszlo Ersek ("organizer")<br />
* Amit Shah<br />
* Andreas Färber<br />
* &lt;add your name here&gt;<br />
<br />
== BoF idea template ==<br />
<br />
<pre><br />
=== TITLE ===<br />
<br />
'''Summary:''' Short description of the idea<br />
<br />
Detailed description of the idea.<br />
<br />
'''Links:'''<br />
* Wiki links to relevant material<br />
* External links to mailing lists or web sites<br />
<br />
'''People:'''<br />
* Your Name (organizer)<br />
* People that want to attend this session<br />
</pre></div>AFhttps://linux-kvm.org/index.php?title=PowerPC_Hypercall_ABI&diff=4550PowerPC Hypercall ABI2012-06-19T16:19:26Z<p>AF: Remove spam</p>
<hr />
<div>= Embedded Hypervisor ABI (draft) =<br />
<br />
The Embedded Hypervisor workgroup decided to use a BEAT style ABI.<br />
<br />
== Hypercall Instruction ==<br />
<br />
The hypercall instruction on legacy Book E implementations shall be the pattern 0x44000022 (SC with LEVEL=1).<br />
<br />
Programming Note: When running on implementations which implement the "embedded hypervisor" architecture, the guest or host may replace the guest hypercall instructions with the architecturally defined hypercall instruction at runtime.<br />
<br />
== Parameter Passing ==<br />
<br />
The hypercall number shall be contained in ''r11'' (like system calls in BEAT ABIs).<br />
<br />
Input parameters shall be contained in ''r3'' through ''r10'', inclusive.<br />
<br />
Hypercalls shall return a success code and place this value in ''r3''.<br />
<br />
Further output parameters shall be contained in ''r4'' through ''r11'', inclusive.<br />
<br />
If more data must be transferred in either direction in a single hypercall, that data must be placed into memory, and that must be specified by the hypercall API (the ABI does not define this behavior).<br />
<br />
=== Summary of Register Usage ===<br />
<br />
Contents of registers that are considered "Volatile" ''will not'' be preserved across a hypercall invocation:<br />
<br />
{|<br />
! Register <br />
! Description <br />
|-<br />
<br />
| r0 <br />
| Volatile <br />
|-<br />
<br />
| r1-r2 <br />
| Non-Volatile <br />
|-<br />
<br />
| r3 <br />
| Volatile input parameter and return value <br />
|-<br />
<br />
| r4 - r10 <br />
| Volatile input parameters and output values <br />
|-<br />
<br />
| r11 <br />
| Hypercall Token and output value <br />
|-<br />
<br />
| r12 <br />
| Volatile <br />
|-<br />
<br />
| r13 - r31 <br />
| Non-Volatile <br />
|-<br />
<br />
| LR <br />
| Non-Volatile <br />
|-<br />
<br />
| CTR <br />
| Non-Volatile <br />
|-<br />
<br />
| XER <br />
| Non-Volatile <br />
|-<br />
<br />
| CR2-CR4 Fields <br />
| Non-Volatile <br />
|-<br />
<br />
| Remaining CR fields <br />
| Volatile <br />
|-<br />
<br />
| Other Registers <br />
| Non-Volatile <br />
|}<br />
<br />
Contents of registers that are considered "Non-Volatile" ''shall'' be preserved across hypercalls.<br />
<br />
/!\ The content of non-volatile registers must be completely preserved, regardless of the size the register and the state of the processor at the time of hypercall invocation. For example, all 64 bits of a 64-bit register must be preserved even if MSR[SF] or MSR[CM] specifies 32-bit mode.<br />
<br />
== TODO ==<br />
<br />
Endianness<br />
<br />
= Background =<br />
<br />
== Introduction to Hypervisor Calls ==<br />
This page describes the existing hcall ABI defined by the various Hypervisors available for the PowerPC platform.<br />
<br />
Known Hypervisor `hcall()` ABIs are:<br />
# PAPR ABI, as used by IBM PHYP Hypervisor and Xen on POWER<br />
# BEAT ABI, as used by Toshiba CellEB<br />
# PS3 ABI, as used by Sony PS3<br />
<br />
== The Hypervisor Call Mechanism ==<br />
Calls to the hypervisor layer are performed by executing an instruction that causes an exception, in much the same way as a Unix System Call is performed. The first argument is a token that designates that actual function to perform. The remaining arguments and there interpretation is specific to the function of the `hcall()`.<br />
<br />
The `hcall` function depends on an instruction that can "trap" to the hypervisor.<br />
Some chip implementations have a modified system call (LEVEL=1) that traps directly to the processor mode that the hypervisor runs in. In the case where the there the processor does not have this special form it is suggest that the system call instruction is used where `r0` is `-1`.<br />
<br />
The definition for HSC is as follows:<br />
<code><br />
#ifdef SC_LEVEL<br />
#define HSC .long 0x44000022 /* SC with LEVEL=1 */<br />
#elseif<br />
#define HSC li r0,-1; sc<br />
#endif<br />
</code><br />
<br />
/!\ In order to safely use `r0` the `hcall` definition must have '''full binding''' and '''not''' be inlined. This way the ABI shall guarantee the volatility of `r0`.<br />
<br />
=== C Language Calling Convention ===<br />
<code><br />
int hcall_func(unsigned long opcode, unsigned long ret[], unsigned long arg<n>, ...)<br />
</code><br />
<br />
/!\ Assumes that unsigned long contains the same number of bit as a `GPR`<br />
<br />
* `ret[]`, This is an array of return values that the `hcall_func()` gives back to the caller.<br />
<br />
* `arg<n>`, The input arguments where `n` is 1 thru 8.<br />
<br />
=== Example Usage ===<br />
The following is a C function using a C language binding for an `hcall`<br />
<code><br />
void<br />
example(unsigned long arg1, unsigned long arg2)<br />
{<br />
int rc;<br />
unsigned long results[2];<br />
<br />
rc = hcall_ex(results, arg1, arg2);<br />
if (rc != H_Success) {<br />
... Failure Case ...<br />
}<br />
... return values are in results array ...<br />
}<br />
</code><br />
<br />
== PAPR ABI ==<br />
<br />
The PAPR Spec is available thru [http://power.org Power.org]. <br />
<br />
=== Inputs ===<br />
The PAPR ABI expects when the call is placed requires the '''token''' for the specific `hcall` to be place in `r3`, the remaining parameters for the `hcall` occupy `r4` thru `r11`.<br />
<br />
=== Outputs ===<br />
Upon completion of the `hcall`, a return code indicating status will be placed `r3` and subsequent registers `r4` thru `r11` will contain additional returned values if any.<br />
<br />
=== Volatile State ===<br />
The native function calling ABI is respected with respect to non-volatiles and typically guarantees extra non-volatiles, specifically:<br />
<br />
<br />
{|<br />
! Register <br />
! Description <br />
|-<br />
<br />
| r0-r1 <br />
| Non-Volatile <br />
|-<br />
<br />
| r3 <br />
| Volatile parameter and return value for status <br />
|-<br />
<br />
| r4 - r11 <br />
| Volatile <br />
|-<br />
<br />
| r12 <br />
| Volatile <br />
|-<br />
<br />
| r13 - r31 <br />
| Non-Volatile <br />
|-<br />
<br />
| LR <br />
| Non-Volatile <br />
|-<br />
<br />
| CTR <br />
| Non-Volatile <br />
|<br />
<br />
| XER <br />
| Non-Volatile <br />
|-<br />
<br />
| CR0-CR7 <br />
| Non-Volatile <br />
|}<br />
<br />
(!) Xen `hcall()s` that are not inherited from the PAPR continue to use `r3` for return code but use memory references for additional return information. :o<br />
<br />
=== Example Definition ===<br />
<br />
Example of creating a C callable function that perform an `hcall()` called `H_EX` for PowerPC 64 bit ELF ABI:<br />
<br />
==== hcall_ex_64.s ====<br />
<code><br />
.align 3<br />
.globl hcall_ex<br />
# Insert ABI specific instruction to make symbol callable by C hcall_ex:<br />
std r3,-8(1) # r3 (array of values) stored in stack<br />
li r3,H_EX # load r3 with hypervisor code<br />
HSC # Hypervisor Trap<br />
ld r12,-8(1) # reload array into r12<br />
cmpi 0,12,0 # only store return regs if array is non-NULL<br />
bne ret2 # this hcall() only returns contents of r4,r5<br />
blr # return no values<br />
<br />
ret8: std r11,(7 * 8)(r12)<br />
ret7: std r10,(6 * 8)(r12)<br />
ret6: std r9,(5 * 8)(r12)<br />
ret5: std r8,(4 * 8)(r12)<br />
ret4: std r7,(3 * 8)(r12)<br />
ret3: std r6,(2 * 8)(r12)<br />
ret2: std r5,(1 * 8)(r12)<br />
ret1: std r4,(0 * 8)(r12)<br />
blr<br />
</code><br />
<br />
(!) 32-bit variant of this function would use `lwz` and `stw`<br />
/!\ `r11` on the hypervisor side will require to be placed in the stack when switching back to C, please see the PowerPC ELF ABI for details<br />
<br />
== BEAT ABI ==<br />
The BEAT ABI is used by CellEB Hypervisor from Toshiba<br />
<br />
=== Inputs ===<br />
The BEAT ABI expects when the call is placed requires the '''token''' for the specific `hcall` to be place in `r11`, the remaining parameters for the `hcall` occupy `r3` thru `r10`.<br />
<br />
=== Outputs ===<br />
Upon completion of the `hcall`, a return code indicating status will be placed `r3` and subsequent registers `r4` thru `r11` will contain additional returned values if any.<br />
<br />
=== Volatile State ===<br />
The native function calling ABI is respected with respect to non-volatiles and typically guarantees extra non-volatiles, specifically:<br />
<br />
<br />
{|<br />
! Register <br />
! Description <br />
|}<br />
<br />
== PS3 ABI ==<br />
The PS3 ABI is used by Playstation 3 Hypervisor from Sony<br />
<br />
=== Inputs ===<br />
The BEAT ABI expects when the call is placed requires the '''token''' for the specific `hcall` to be place in `r11`, the remaining parameters for the `hcall` occupy `r3` thru `r10`.<br />
<br />
=== Outputs ===<br />
Upon completion of the `hcall`, a return code indicating status will be placed `r3` and subsequent registers `r4` thru `r11` will contain additional returned values if any.<br />
<br />
=== Volatile State ===<br />
The native function calling ABI is respected with respect to non-volatiles and typically guarantees extra non-volatiles, specifically:<br />
<br />
<br />
{|<br />
! Register <br />
! Description <br />
|}<br />
<br />
----<br />
[[Category:PowerPC]]</div>AF