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

Re: [PATCH v5 10/11] hvm/ioreq: Negotiate extended destination ID support per ioreq server



On Thu, Sep 03, 2026 at 04:14:08PM +0200, Julian Vetter wrote:
> diff --git a/tools/include/xendevicemodel.h b/tools/include/xendevicemodel.h
> index 698d719119..72994d1313 100644
> --- a/tools/include/xendevicemodel.h
> +++ b/tools/include/xendevicemodel.h
> @@ -44,12 +44,13 @@ int xendevicemodel_close(xendevicemodel_handle *dmod);
>   * @parm domid the domain id to be serviced
>   * @parm handle_bufioreq how should the IOREQ Server handle buffered
>   *                       requests (HVM_IOREQSRV_BUFIOREQ_*)?
> + * @parm flags bitmask of XEN_DMOP_IOREQ_SERVER_* capability flags (0 if 
> none).
>   * @parm id pointer to an ioservid_t to receive the IOREQ Server id.
>   * @return 0 on success, -1 on failure.
>   */
>  int xendevicemodel_create_ioreq_server(
>      xendevicemodel_handle *dmod, domid_t domid, int handle_bufioreq,
> -    ioservid_t *id);
> +    uint8_t flags, ioservid_t *id);

You can't do that. libxendevicemodel is supposed to have a stable ABI so
we can't change the prototype of existing functions. I think this will
need a new function, with suffix "_v2", or any other different name.

Then, why limit "flags" to 8bits ? Just change that to 64bits at no cost
(maybe a little to check that all flags exist) and we won't need to look
back, hopefully.

Thanks,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.