Re: [Xen-devel] [PATCH 4/7] ioreq: allow registering internal ioreq server handler

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
> Sent: 22 August 2019 08:44
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Jan Beulich <jbeulich@xxxxxxxx>; Andrew 
> Cooper
> <Andrew.Cooper3@xxxxxxxxxx>; Wei Liu <wl@xxxxxxx>
> 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 <roger.pau@xxxxxxxxxx>
> > > Sent: 21 August 2019 15:59
> > > To: xen-devel@xxxxxxxxxxxxxxxxxxxx
> > > Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>; Paul Durrant 
> > > <Paul.Durrant@xxxxxxxxxx>; Jan Beulich
> > > <jbeulich@xxxxxxxx>; Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Wei Liu 
> > > <wl@xxxxxxx>
> > > 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
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel