diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/qapi-code-gen.txt | 2 | ||||
| -rw-r--r-- | docs/specs/ppc-spapr-hcalls.txt | 78 | ||||
| -rw-r--r-- | docs/usb-storage.txt | 38 |
3 files changed, 118 insertions, 0 deletions
diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt index ad11767a2f..cccb11e562 100644 --- a/docs/qapi-code-gen.txt +++ b/docs/qapi-code-gen.txt @@ -220,6 +220,8 @@ Example: #endif mdroth@illuin:~/w/qemu2.git$ +(The actual structure of the visit_type_* functions is a bit more complex +in order to propagate errors correctly and avoid leaking memory). === scripts/qapi-commands.py === diff --git a/docs/specs/ppc-spapr-hcalls.txt b/docs/specs/ppc-spapr-hcalls.txt new file mode 100644 index 0000000000..52ba8d42ab --- /dev/null +++ b/docs/specs/ppc-spapr-hcalls.txt @@ -0,0 +1,78 @@ +When used with the "pseries" machine type, QEMU-system-ppc64 implements +a set of hypervisor calls using a subset of the server "PAPR" specification +(IBM internal at this point), which is also what IBM's proprietary hypervisor +adheres too. + +The subset is selected based on the requirements of Linux as a guest. + +In addition to those calls, we have added our own private hypervisor +calls which are mostly used as a private interface between the firmware +running in the guest and QEMU. + +All those hypercalls start at hcall number 0xf000 which correspond +to a implementation specific range in PAPR. + +- H_RTAS (0xf000) + +RTAS is a set of runtime services generally provided by the firmware +inside the guest to the operating system. It predates the existence +of hypervisors (it was originally an extension to Open Firmware) and +is still used by PAPR to provide various services that aren't performance +sensitive. + +We currently implement the RTAS services in QEMU itself. The actual RTAS +"firmware" blob in the guest is a small stub of a few instructions which +calls our private H_RTAS hypervisor call to pass the RTAS calls to QEMU. + +Arguments: + + r3 : H_RTAS (0xf000) + r4 : Guest physical address of RTAS parameter block + +Returns: + + H_SUCCESS : Successully called the RTAS function (RTAS result + will have been stored in the parameter block) + H_PARAMETER : Unknown token + +- H_LOGICAL_MEMOP (0xf001) + +When the guest runs in "real mode" (in powerpc lingua this means +with MMU disabled, ie guest effective == guest physical), it only +has access to a subset of memory and no IOs. + +PAPR provides a set of hypervisor calls to perform cachable or +non-cachable accesses to any guest physical addresses that the +guest can use in order to access IO devices while in real mode. + +This is typically used by the firmware running in the guest. + +However, doing a hypercall for each access is extremely inefficient +(even more so when running KVM) when accessing the frame buffer. In +that case, things like scrolling become unusably slow. + +This hypercall allows the guest to request a "memory op" to be applied +to memory. The supported memory ops at this point are to copy a range +of memory (supports overlap of source and destination) and XOR which +is used by our SLOF firmware to invert the screen. + +Arguments: + + r3: H_LOGICAL_MEMOP (0xf001) + r4: Guest physical address of destination + r5: Guest physical address of source + r6: Individual element size + 0 = 1 byte + 1 = 2 bytes + 2 = 4 bytes + 3 = 8 bytes + r7: Number of elements + r8: Operation + 0 = copy + 1 = xor + +Returns: + + H_SUCCESS : Success + H_PARAMETER : Invalid argument + diff --git a/docs/usb-storage.txt b/docs/usb-storage.txt new file mode 100644 index 0000000000..e58e849d4d --- /dev/null +++ b/docs/usb-storage.txt @@ -0,0 +1,38 @@ + +qemu usb storage emulation +-------------------------- + +QEMU has two emulations for usb storage devices. + +Number one emulates the classic bulk-only transport protocol which is +used by 99% of the usb sticks on the marked today and is called +"usb-storage". Usage (hooking up to xhci, other host controllers work +too): + + qemu ${other_vm_args} \ + -drive if=none,id=stick,file=/path/to/file.img \ + -device nec-usb-xhci,id=xhci \ + -device usb-storage,bus=xhci.0,drive=stick + + +Number two is the newer usb attached scsi transport. This one doesn't +automagically create a scsi disk, so you have to explicitly attach one +manually. Multiple logical units are supported. Here is an example +with tree logical units: + + qemu ${other_vm_args} \ + -drive if=none,id=uas-disk1,file=/path/to/file1.img \ + -drive if=none,id=uas-disk2,file=/path/to/file2.img \ + -drive if=none,id=uas-cdrom,media=cdrom,file=/path/to/image.iso \ + -device nec-usb-xhci,id=xhci \ + -device usb-uas,id=uas,bus=xhci.0 \ + -device scsi-hd,bus=uas.0,scsi-id=0,lun=0,drive=uas-disk1 \ + -device scsi-hd,bus=uas.0,scsi-id=0,lun=1,drive=uas-disk2 \ + -device scsi-cd,bus=uas.0,scsi-id=0,lun=5,drive=uas-cdrom + + +enjoy, + Gerd + +-- +Gerd Hoffmann <kraxel@redhat.com> |