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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 :).


Alex


_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm




[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux