On 26.09.2013, at 00:26, Alexander Graf wrote: > > 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@xxxxxxx> 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@xxxxxxxxxx> >>>>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@xxxxxxxxxx> >>>>> --- >>>>> 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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
