> -----Original Message----- > From: Roger Pau Monne <[email protected]> > Sent: 22 August 2019 08:24 > To: Paul Durrant <[email protected]> > Cc: [email protected]; Jan Beulich <[email protected]>; Andrew > Cooper > <[email protected]>; Wei Liu <[email protected]> > Subject: Re: [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 <[email protected]> > > > Sent: 21 August 2019 15:59 > > > To: [email protected] > > > Cc: Roger Pau Monne <[email protected]>; Jan Beulich > > > <[email protected]>; Andrew Cooper > > > <[email protected]>; Wei Liu <[email protected]>; Paul Durrant > > > <[email protected]> > > > 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? >
Yes, that's basically what I was thinking initially although, as you observe, in the thread for patch #3 having two smaller consecutive ranges would be more convenient. Paul _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
