From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [PATCH v3 31/32] arm64: KVM: userspace API documentation Date: Tue, 23 Apr 2013 16:02:52 -0700 Message-ID: <20130423230252.GO20569@gmail.com> References: <1365437854-30214-1-git-send-email-marc.zyngier@arm.com> <1365437854-30214-32-git-send-email-marc.zyngier@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, catalin.marinas@arm.com, will.deacon@arm.com To: Marc Zyngier Return-path: Received: from mail-pa0-f51.google.com ([209.85.220.51]:43993 "EHLO mail-pa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751411Ab3DWXCd (ORCPT ); Tue, 23 Apr 2013 19:02:33 -0400 Received: by mail-pa0-f51.google.com with SMTP id jh10so776268pab.24 for ; Tue, 23 Apr 2013 16:02:32 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1365437854-30214-32-git-send-email-marc.zyngier@arm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Apr 08, 2013 at 05:17:33PM +0100, Marc Zyngier wrote: > Unsurprisingly, the arm64 userspace API is extremely similar to > the 32bit one, the only significant difference being the ONE_REG > register mapping. >=20 > Signed-off-by: Marc Zyngier > --- > Documentation/virtual/kvm/api.txt | 55 +++++++++++++++++++++++++----= ---------- > 1 file changed, 36 insertions(+), 19 deletions(-) >=20 > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtua= l/kvm/api.txt > index 119358d..7c3385e 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -280,7 +280,7 @@ kvm_run' (see below). > 4.11 KVM_GET_REGS > =20 > Capability: basic > -Architectures: all except ARM > +Architectures: all except ARM, arm64 > Type: vcpu ioctl > Parameters: struct kvm_regs (out) > Returns: 0 on success, -1 on error > @@ -301,7 +301,7 @@ struct kvm_regs { > 4.12 KVM_SET_REGS > =20 > Capability: basic > -Architectures: all except ARM > +Architectures: all except ARM, arm64 > Type: vcpu ioctl > Parameters: struct kvm_regs (in) > Returns: 0 on success, -1 on error > @@ -587,7 +587,7 @@ struct kvm_fpu { > 4.24 KVM_CREATE_IRQCHIP > =20 > Capability: KVM_CAP_IRQCHIP > -Architectures: x86, ia64, ARM > +Architectures: x86, ia64, ARM, arm64 > Type: vm ioctl > Parameters: none > Returns: 0 on success, -1 on error > @@ -595,14 +595,14 @@ Returns: 0 on success, -1 on error > Creates an interrupt controller model in the kernel. On x86, create= s a virtual > ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus t= o have a > local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC= ; GSI 16-23 > -only go to the IOAPIC. On ia64, a IOSAPIC is created. On ARM, a GIC= is > +only go to the IOAPIC. On ia64, a IOSAPIC is created. On ARM/arm64,= a GIC is > created. > =20 > =20 > 4.25 KVM_IRQ_LINE > =20 > Capability: KVM_CAP_IRQCHIP > -Architectures: x86, ia64, arm > +Architectures: x86, ia64, arm, arm64 > Type: vm ioctl > Parameters: struct kvm_irq_level > Returns: 0 on success, -1 on error > @@ -612,9 +612,10 @@ On some architectures it is required that an int= errupt controller model has > been previously created with KVM_CREATE_IRQCHIP. Note that edge-tri= ggered > interrupts require the level to be set to 1 and then back to 0. > =20 > -ARM can signal an interrupt either at the CPU level, or at the in-ke= rnel irqchip > -(GIC), and for in-kernel irqchip can tell the GIC to use PPIs design= ated for > -specific cpus. The irq field is interpreted like this: > +ARM/arm64 can signal an interrupt either at the CPU level, or at the > +in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC = to > +use PPIs designated for specific cpus. The irq field is interpreted > +like this: > =20 > =A0bits: | 31 ... 24 | 23 ... 16 | 15 ... 0 | > field: | irq_type | vcpu_index | irq_id | > @@ -1802,6 +1803,19 @@ ARM 32-bit VFP control registers have the foll= owing id bit patterns: > ARM 64-bit FP registers have the following id bit patterns: > 0x4002 0000 0012 0 > =20 > + > +arm64 registers are mapped using the lower 32 bits. The upper 16 of > +that is the register group type, or coprocessor number: > + > +arm64 core/FP-SIMD registers have the following id bit patterns: > + 0x6002 0000 0010 > + > +arm64 CCSIDR registers are demultiplexed by CSSELR value: > + 0x6002 0000 0011 00 > + > +arm64 system registers have the following id bit patterns: > + 0x6002 0000 0013 > + I think these size encodings are 4 bits off, and not accurate for for the core registers, which have variable sizes, which should be indicate= d here (unless you decide for a separate category as per my other comment). > 4.69 KVM_GET_ONE_REG > =20 > Capability: KVM_CAP_ONE_REG > @@ -2165,7 +2179,7 @@ valid entries found. > 4.77 KVM_ARM_VCPU_INIT > =20 > Capability: basic > -Architectures: arm > +Architectures: arm, arm64 > Type: vcpu ioctl > Parameters: struct struct kvm_vcpu_init (in) > Returns: 0 on success; -1 on error > @@ -2184,12 +2198,14 @@ should be created before this ioctl is invoke= d. > Possible features: > - KVM_ARM_VCPU_POWER_OFF: Starts the CPU in a power-off state. > Depends on KVM_CAP_ARM_PSCI. > + - KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode. > + Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only). > =20 > =20 > 4.78 KVM_GET_REG_LIST > =20 > Capability: basic > -Architectures: arm > +Architectures: arm, arm64 > Type: vcpu ioctl > Parameters: struct kvm_reg_list (in/out) > Returns: 0 on success; -1 on error > @@ -2209,7 +2225,7 @@ KVM_GET_ONE_REG/KVM_SET_ONE_REG calls. > 4.80 KVM_ARM_SET_DEVICE_ADDR > =20 > Capability: KVM_CAP_ARM_SET_DEVICE_ADDR > -Architectures: arm > +Architectures: arm, arm64 > Type: vm ioctl > Parameters: struct kvm_arm_device_address (in) > Returns: 0 on success, -1 on error > @@ -2230,18 +2246,19 @@ can access emulated or directly exposed devic= es, which the host kernel needs > to know about. The id field is an architecture specific identifier f= or a > specific device. > =20 > -ARM divides the id field into two parts, a device id and an address = type id > -specific to the individual device. > +ARM/arm64 divides the id field into two parts, a device id and an > +address type id specific to the individual device. > =20 > =A0bits: | 63 ... 32 | 31 ... 16 | 15 ... = 0 | > field: | 0x00000000 | device id | addr type id = | > =20 > -ARM currently only require this when using the in-kernel GIC support= for the > -hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2 as the device i= d. When > -setting the base address for the guest's mapping of the VGIC virtual= CPU > -and distributor interface, the ioctl must be called after calling > -KVM_CREATE_IRQCHIP, but before calling KVM_RUN on any of the VCPUs. = Calling > -this ioctl twice for any of the base addresses will return -EEXIST. > +ARM/arm64 currently only require this when using the in-kernel GIC > +support for the hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2 > +as the device id. When setting the base address for the guest's > +mapping of the VGIC virtual CPU and distributor interface, the ioctl > +must be called after calling KVM_CREATE_IRQCHIP, but before calling > +KVM_RUN on any of the VCPUs. Calling this ioctl twice for any of th= e > +base addresses will return -EEXIST. > =20 > =20 > 5. The kvm_run structure > --=20 > 1.8.1.4 >=20 >=20 > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html