[PATCH v4 4/4] KVM: Add documentation for KVM_ARM_PREFERRED_TARGET ioctl

[Alexander Graf]

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

> On Wed, Sep 25, 2013 at 05:58:07PM +0530, Anup Patel wrote:
>> On Wed, Sep 25, 2013 at 5:43 PM, Alexander Graf <agraf at suse.de> wrote:
>>> 
>>> On 25.09.2013, at 11:26, Anup Patel wrote:
>>> 
>>>> 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 <anup.patel at linaro.org>
>>>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
>>>> ---
>>>> 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 :).


Alex