Re: Changing user-mode interfaces

[Owen Smith <owen.smith@xxxxxxxxxx>]

XenAgent in the XenIface package currently uses the IOCTLs directly - this shouldnt be too difficult to rewrite to be managed by xencontrol, other than the RegisterDeviceNotification calls on the device handle (to detect xeniface removal)

XenServer's management agent uses the IOCTLs directly (via C# PInvoke) in a similar manner. The additional problem here would be requiring DllImport from a file not supplied with the agent binaries would make distribution difficult, especially via Windows Update.

In the short term, XenServer does not use the Gnttab IOCTLs or xencontrol.dll, so any changes to this set of IOCTLs will not affect us directly.

In general, I'm opposed to changing IOCTL definitions, as it can easily break when using a package based distribution (i.e. it's impossible to guarantee all components, like xeniface and an agent, are kept in sync and binary compatible). Adding IOCTLs to resolve the RequestID changes shouldnt be an issue.

Owen

On Thu, Nov 30, 2023 at 11:10 AM Paul Durrant <xadimgnik@xxxxxxxxx> wrote:

Top-posting for the sake of consistency...

I think the stable API is that exported by xencontrol.dll itself. It is
part of the xeniface package so I consider anything 'underneath' it to
be unstable.

Owen, how difficult would it be to port to use the DLL rather than using
the IOCTLs directly?

   Paul

On 29/11/2023 12:00, Owen Smith wrote:
> At XenServer we dont use the xencontrol.dll interface, but do use the
> IOCTLs directly. I'd prefer to keep the IOCTL parameters fixed for each
> particular IOCTL, but adding new IOCTLs should be fine (IIRC, there are
> 'gaps' in the numbering between different codes to facilitate this).
>
> Owen
>
> On Tue, Nov 28, 2023 at 10:40 AM Rafał Wojdyła
> <omeg@xxxxxxxxxxxxxxxxxxxxxx <mailto:omeg@xxxxxxxxxxxxxxxxxxxxxx>> wrote:
>
>     Hello,
>
>     What is the policy on potentially breaking changes in the user-mode
>     interface? I have some additions to the gnttab IOCTL (sharing already
>     existing memory in addition to driver-allocated one) which require
>     changing the xencontrol interface or adding another version similar to
>     how the driver interfaces work.
>
>     Additionally I'd like to change how the bookkeeping of gnttab user
>     requests is done: currently each IOCTL contains a process-unique ID
>     as a
>     part of the input. This ID is managed by xencontrol and that can
>     lead to
>     bugs if a process opens more than one xencontrol handle (IDs will be
>     duplicated, the driver checks for that but the requests will fail).
>
>     I think I was the one who wrote that code in the first place (it has
>     been some time... ;), but it seems like we can just remove the request
>     IDs and xeniface would track gnttab requests by the user-mode
>     address of
>     the shared memory (per-process of course). I don't think it's possible
>     to share the same region twice so that should be fine?
>
>     So since the "new" IOCTL parameters would get rid of the ID parameter
>     (and introduce optional address parameter for memory sharing) I'm
>     wondering what's the best way to do the change -- introducing a new
>     version is probably the safest, but it would be a bit messy. I wonder
>     who else besides us (ITL) even uses this code... :)
>
>     Anyway, what's your thoughts on this?
>
>     --
>     Rafał Wojdyła
>     Invisible Things Lab
>