[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <15aa881f-5cf1-446e-a71e-f62d24e87500@app.fastmail.com>
Date: Fri, 24 Feb 2023 14:20:40 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Srinivas Kandagatla" <srinivas.kandagatla@...aro.org>,
"Elliot Berman" <quic_eberman@...cinc.com>,
"Alex Elder" <elder@...aro.org>,
"Jonathan Corbet" <corbet@....net>,
"Prakruthi Deepak Heragu" <quic_pheragu@...cinc.com>
Cc: "Murali Nalajala" <quic_mnalajal@...cinc.com>,
"Trilok Soni" <quic_tsoni@...cinc.com>,
"Srivatsa Vaddagiri" <quic_svaddagi@...cinc.com>,
"Carl van Schaik" <quic_cvanscha@...cinc.com>,
"Dmitry Baryshkov" <dmitry.baryshkov@...aro.org>,
"Bjorn Andersson" <andersson@...nel.org>,
"Konrad Dybcio" <konrad.dybcio@...aro.org>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"Rob Herring" <robh+dt@...nel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
"Bagas Sanjaya" <bagasdotme@...il.com>,
"Catalin Marinas" <catalin.marinas@....com>,
"Jassi Brar" <jassisinghbrar@...il.com>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v10 10/26] gunyah: vm_mgr: Introduce basic VM Manager
On Fri, Feb 24, 2023, at 11:29, Srinivas Kandagatla wrote:
> On 23/02/2023 22:40, Elliot Berman wrote:
>>>> Does this means adding #define GH_VM_DEFAULT_ARG 0 ? I am not sure
>>>> yet what arguments to add here.
>>>>
>>>> The ABI can add new "long" values to GH_CREATE_VM and that wouldn't
>>>
>>> Sorry, that is exactly what we want to avoid, we can not change the
>>> UAPI its going to break the userspace.
>>>
>>>> break compatibility with old kernels; old kernels reject it as -EINVAL.
>>>
>>> If you have userspace built with older kernel headers then that will
>>> break. Am not sure about old-kernels.
>>>
>>> What exactly is the argument that you want to add to GH_CREATE_VM?
>>>
>>> If you want to keep GH_CREATE_VM with no arguments that is fine but
>>> remove the conflicting comments in the code and document so that its
>>> not misleading readers/reviewers that the UAPI is going to be modified
>>> in near future.
>>>
>>>
>>
>> The convention followed here comes from KVM_CREATE_VM. Is this ioctl
>> considered bad example?
>>
>
> It is recommended to only use _IO for commands without arguments, and
> use pointers for passing data. Even though _IO can indicate either
> commands with no argument or passing an integer value instead of a
> pointer. Am really not sure how this works in compat case.
>
> Am sure there are tricks that can be done with just using _IO() macro
> (ex vfio), but this does not mean that we should not use _IOW to be more
> explicit on the type and size of argument that we are expecting.
>
> On the other hand If its really not possible to change this IOCTL to
> _IOW and argument that you are referring would be with in integer range,
> then what you have with _IO macro should work.
Passing an 'unsigned long' value instead of a pointer is fine for compat
mode, as a 32-bit compat_ulong_t always fits inside of the 64-bit
unsigned long. The downside is that portable code cannot have a
single ioctl handler function that takes both commands with pointers
and other commands with integer arguments, as some architectures
(i.e. s390, possibly arm64+morello in the future) need to mangle
pointer arguments using compat_ptr() but must not do that on integer
arguments.
Arnd
Powered by blists - more mailing lists