From: Rusty Russell <rusty.russell@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Avi Kivity <avi@redhat.com>,
Christoffer Dall <c.dall@virtualopensystems.com>,
Alexander Graf <agraf@suse.de>,
kvmarm@lists.cs.columbia.edu, kvm-devel <kvm@vger.kernel.org>
Subject: Re: [RFC 0/5] Making KVM_GET_ONE_REG/KVM_SET_ONE_REG generic.
Date: Thu, 30 Aug 2012 04:09:07 +0930 [thread overview]
Message-ID: <87mx1dsfuc.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CAFEAcA8Gf3hJ3VrSV01OZtq8iF0+Nj0sizaPKZoAQ8QomWiK+g@mail.gmail.com>
Peter Maydell <peter.maydell@linaro.org> writes:
> On 29 August 2012 00:37, Rusty Russell <rusty.russell@linaro.org> wrote:
>> This compiles, completely untested, but it's my attempt to give
>> Avi (and Alexander) what he asked for in a generic register accessor.
>>
>> Mingled in these patches is the conversion of the latest KVM ARM code,
>> which is the first proposed user: by the end, we use these accessors for
>> *every* register and piece of state.
>>
>> GET_MULTI/SET_MULTI is an obvious extension which is not yet
>> implemented.
>
> Hi Rusty.
>
> I don't see any api.txt patches in here, did I miss them?
> (your cover letter doesn't include a diffstat...)
>
> I don't particularly have comments on the implementation but I would
> like to see the kernel-userspace ABI clearly described rather than
> having to infer it from the code. (including the complete set of
> index mappings for the ARM registers that will use this)
It would look something like this:
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 19d8915..c0453d7 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -293,7 +293,7 @@ kvm_run' (see below).
4.11 KVM_GET_REGS
Capability: basic
-Architectures: all
+Architectures: all except ARM
Type: vcpu ioctl
Parameters: struct kvm_regs (out)
Returns: 0 on success, -1 on error
@@ -314,7 +314,7 @@ struct kvm_regs {
4.12 KVM_SET_REGS
Capability: basic
-Architectures: all
+Architectures: all except ARM
Type: vcpu ioctl
Parameters: struct kvm_regs (in)
Returns: 0 on success, -1 on error
@@ -1733,6 +1733,17 @@ registers, find a list below:
| |
PPC | KVM_REG_PPC_HIOR | 64
+ARM registers are mapped using the lower 32 bits. The upper 16 of that
+is the coprocessor number (or 16 for core registers):
+
+ARM 32-bit CP15 registers have the following id bit patterns:
+ 0x4002 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
+
+ARM 64-bit CP15 registers have the following id bit patterns:
+ 0x4003 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
+
+ARM core registers have the following id format:
+ 0x4003 0000 0010 <offset in struct kvm_regs, divided by 4>
4.69 KVM_GET_ONE_REG
@@ -1986,50 +1997,26 @@ the virtualized real-mode area (VRMA) facility, the kernel will
re-create the VMRA HPTEs on the next KVM_RUN of any vcpu.)
-4.76 KVM_VCPU_GET_MSR_INDEX_LIST
+4.76 KVM_VCPU_GET_REG_LIST
-Capability: basic
+Capability: KVM_CAP_REG_LIST
Architectures: arm
Type: vcpu ioctl
-Parameters: struct kvm_msr_list (in/out)
+Parameters: struct kvm_reg_list (in/out)
Returns: 0 on success; -1 on error
Errors:
- E2BIG: the msr index list is too big to fit in the array specified by
- the user.
+ E2BIG: the reg index list is too big to fit in the array specified by
+ the user (the number required will be written into n).
struct kvm_msr_list {
- __u32 nmsrs; /* number of msrs in entries */
- __u32 indices[0];
+ __u64 n; /* number of registers in reg[] */
+ __u64 reg[0];
};
-This ioctl returns the guest special registers that are supported, and
-is only valid after KVM_ARM_VCPU_INIT has been performed to initialize
-the vcpu type and features. It is otherwise the equivalent of the
-x86-specific KVM_GET_MSR_INDEX_LIST, for arm's coprocessor registers
-and other non-register state.
-
-The numbering for the indices for coprocesors is simple: the upper 16
-bits are the coprocessor number. If it's > 15, it's something else,
-for future expansion.
-
-Bit 15 indicates a 64-bit register. For 64 bit registers the bottom 4
-bits are CRm, the next 4 are opc1 (just like the MCRR/MRCC instruction
-encoding). For 32 bit registers, the bottom 4 bits are CRm, the next
-3 are opc2, the next 4 CRn, and the next 3 opc1 (the same order as the
-MRC/MCR instruction encoding, but not the same bit positions).
-
-64-bit coprocessor register:
- ...|19 18 17 16|15|14 13 12 11 10 9 8| 7 6 5 4 |3 2 1 0|
- ...0 0 | cp num | 1| 0 0 0 0 0 0 0| opc1 | CRm |
-
-32-bit coprocessor register:
- ...|19 18 17 16|15|14|13 12 11|10 9 8 7 |6 5 4 |3 2 1 0|
- ...0 0 | cp num | 0| 0| opc1 | CRn | opc2 | CRm |
-
-Non-coprocessor register:
-
- | 32 31 30 29 28 27 26 25 24 23 22 21 20|19 18 17 16 15 ...
- | < some non-zero value > | ...
+This ioctl returns the guest registers that are supported for the
+KVM_GET_ONE_REG/KVM_SET_ONE_REG calls, and is only valid after
+KVM_ARM_VCPU_INIT has been performed to initialize the vcpu type and
+features.
4.77 KVM_ARM_VCPU_INIT
next prev parent reply other threads:[~2012-08-29 18:39 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-28 23:37 [RFC 0/5] Making KVM_GET_ONE_REG/KVM_SET_ONE_REG generic Rusty Russell
2012-08-28 23:45 ` [RFC 1/5] KVM: Move KVM_SET_ONE_REG/KVM_GET_ONE_REG to generic code Rusty Russell
2012-09-01 9:11 ` Avi Kivity
2012-09-01 10:18 ` Peter Maydell
2012-09-01 10:44 ` Avi Kivity
2012-08-28 23:46 ` [RFC 2/5] KVM: ARM: use KVM_SET_ONE_REG/KVM_GET_ONE_REG Rusty Russell
2012-08-29 15:10 ` Christoffer Dall
2012-08-28 23:47 ` [RFC 3/5] KVM: Add KVM_VCPU_GET_REG_LIST Rusty Russell
2012-08-29 15:13 ` Christoffer Dall
2012-08-28 23:47 ` [RFC 4/5] KVM: ARM: Use KVM_VCPU_GET_REG_LIST Rusty Russell
2012-08-29 15:14 ` Christoffer Dall
2012-08-28 23:48 ` [RFC 5/5] KVM: ARM: Access all registers via KVM_GET_ONE_REG/KVM_SET_ONE_REG Rusty Russell
2012-08-29 15:29 ` Christoffer Dall
2012-09-01 9:14 ` Avi Kivity
2012-08-29 15:36 ` Peter Maydell
2012-08-29 18:21 ` Rusty Russell
2012-09-01 9:16 ` Avi Kivity
2012-09-01 10:25 ` Peter Maydell
2012-09-01 19:40 ` Christoffer Dall
2012-09-04 13:09 ` Peter Maydell
2012-09-04 14:29 ` Christoffer Dall
2012-09-05 6:37 ` Rusty Russell
2012-08-29 18:16 ` Rusty Russell
2012-08-29 16:30 ` [RFC 0/5] Making KVM_GET_ONE_REG/KVM_SET_ONE_REG generic Peter Maydell
2012-08-29 18:39 ` Rusty Russell [this message]
2012-09-01 9:21 ` Avi Kivity
2012-09-01 12:35 ` Rusty Russell
2012-09-03 9:20 ` Avi Kivity
2012-09-03 12:33 ` Rusty Russell
2012-09-03 12:49 ` Peter Maydell
2012-09-04 11:48 ` Avi Kivity
2012-09-04 13:59 ` Alexander Graf
2012-09-06 14:44 ` Avi Kivity
2012-09-05 6:43 ` Rusty Russell
2012-09-01 12:28 ` Rusty Russell
2012-09-01 12:37 ` Rusty Russell
2012-09-04 13:31 ` Peter Maydell
2012-09-05 3:15 ` Alexander Graf
2012-09-05 6:48 ` Rusty Russell
2012-09-05 8:52 ` Peter Maydell
2012-09-06 1:44 ` Rusty Russell
2012-09-06 7:37 ` Peter Maydell
2012-09-06 14:48 ` Avi Kivity
2012-09-06 15:08 ` Alexander Graf
2012-09-06 15:16 ` Avi Kivity
2012-09-06 15:23 ` Peter Maydell
2012-09-06 15:35 ` Avi Kivity
2012-09-06 23:00 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mx1dsfuc.fsf@rustcorp.com.au \
--to=rusty.russell@linaro.org \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=c.dall@virtualopensystems.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=peter.maydell@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).