[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/7] ioreq: add internal ioreq initialization support
On Wed, Aug 21, 2019 at 06:24:17PM +0200, Paul Durrant wrote: > > -----Original Message----- > > From: Roger Pau Monne <roger.pau@xxxxxxxxxx> > > Sent: 21 August 2019 15:59 > > To: xen-devel@xxxxxxxxxxxxxxxxxxxx > > Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>; Jan Beulich > > <jbeulich@xxxxxxxx>; Andrew Cooper > > <Andrew.Cooper3@xxxxxxxxxx>; Wei Liu <wl@xxxxxxx>; Paul Durrant > > <Paul.Durrant@xxxxxxxxxx> > > Subject: [PATCH 2/7] ioreq: add internal ioreq initialization support > > > > Add support for internal ioreq servers to initialization and > > deinitialization routines, prevent some functions from being executed > > against internal ioreq servers and add guards to only allow internal > > callers to modify internal ioreq servers. External callers (ie: from > > hypercalls) are only allowed to deal with external ioreq servers. > > It's kind of ugly to have the extra 'internal' argument passed to anything > other than the create function so I wonder whether it would be neater to > encode it in the ioreq server id. I.e. we have distinct id ranges for > internal and external servers. What do you think? That would be fine, I guess I could use the most significant bit in the id to signal whether the server is internal or external, and reject dmop calls that target internal servers based on the provided id. Does that sound sensible? Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |