On 26.09.2013, at 00:26, Alexander Graf wrote:

On 25.09.2013, at 18:19, Christoffer Dall wrote:

quoted

On Wed, Sep 25, 2013 at 05:58:07PM +0530, Anup Patel wrote:

quoted

On Wed, Sep 25, 2013 at 5:43 PM, Alexander Graf [off-list ref] wrote:

quoted

On 25.09.2013, at 11:26, Anup Patel wrote:

quoted

To implement CPU=Host we have added KVM_ARM_PREFERRED_TARGET
vm ioctl which provides information to user space required for
creating VCPU matching underlying Host.

This patch adds info related to this new KVM_ARM_PREFERRED_TARGET
vm ioctl in the KVM API documentation.

Signed-off-by: Anup Patel <redacted>
Signed-off-by: Pranavkumar Sawargaonkar <redacted>
---
Documentation/virtual/kvm/api.txt |   27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 858aecf..f31e6e8 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt

@@ -2303,8 +2303,28 @@ Possible features:
    - KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
      Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).

+4.83 KVM_ARM_PREFERRED_TARGET

Why 4.83 and not 4.86? It feels backwards to rename all these other sections.

I wanted to have KVM_ARM_xxxx IOCTLs located nearby hence
placed KVM_ARM_PREFERRED_TARGET after KVM_ARM_VCPU_INIT.

There is no point in keeping KVM_ARM_PREFERRED_TARGET
after KVM_PPC_RTAS_DEFINE_TOKEN and make
KVM_PPC_RTAS_DEFINE_TOKEN dangle in-between documentation
of various KVM_ARM_xxxx IOCTLs.

I checked the git log and this is not the first time this has happened,
so I think Anup's point here is valid.

Well, I think it makes sense to be consistent here. Maybe we should add a new section for arch specific ioctls so that we get our own number space? But regardless, all subarchs should try and follow the same scheme - regardless of what the scheme is :).

Ok, I think I finally grasped what Anup was trying to say. The ioctl id for this one is 0xaf, in between 0xae (KVM_ARM_VCPU_INIT) and 0xb0 (KVM_GET_REG_LIST), so he wanted to make the documentation follow the ioctl numbering scheme. That makes sense.

However, why do we have this gap there in the first place?


Alex