> -----Original Message----- > From: Roger Pau Monne <[email protected]> > Sent: 22 August 2019 08:44 > To: Paul Durrant <[email protected]> > Cc: [email protected]; Jan Beulich <[email protected]>; Andrew > Cooper > <[email protected]>; Wei Liu <[email protected]> > Subject: Re: [PATCH 4/7] ioreq: allow registering internal ioreq server > handler > > On Wed, Aug 21, 2019 at 06:35:15PM +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]>; Paul Durrant > > > <[email protected]>; Jan Beulich > > > <[email protected]>; Andrew Cooper <[email protected]>; Wei Liu > > > <[email protected]> > > > Subject: [PATCH 4/7] ioreq: allow registering internal ioreq server > > > handler > > > > > > Provide a routine to register the handler for an internal ioreq > > > server. Note the handler can only be set once. > > > > I'd prefer hvm_set_ioreq_handler() and some sort of guard to prevent > > enabling of an internal server > with no handler (probably in the previous patch) would be prudent, I think. > > Right, I will add it. > > > Also, why the set-once semantic? > > Well, I didn't have the need to change the handler of internal ioreq > servers (vPCI) so I've coded it that way. If you think it's better to > allow run time changes of the handler that's fine, I just didn't have > the need for it given the current use-case and I thought it would be > safer. >
I think a more relaxed semantic of only being able to change the handler when the ioreq server is disabled would be fine. Also, I wonder whether you ought to allow handler registration to set some opaque caller context too, rather than assuming that the vcpu is the appropriate context to pass to all handlers? Paul _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
