From: Paul Durrant <Paul.Durrant@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Wei Liu <wl@xen.org>, Jan Beulich <jbeulich@suse.com>,
Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/7] ioreq: allow registering internal ioreq server handler
Date: Thu, 22 Aug 2019 08:38:05 +0000 [thread overview]
Message-ID: <5ac6988a64d14239935a8f7acace5d15@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <20190822074332.7bl42x3gthqji76k@Air-de-Roger>
> -----Original Message-----
> From: Roger Pau Monne <roger.pau@citrix.com>
> Sent: 22 August 2019 08:44
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: xen-devel@lists.xenproject.org; Jan Beulich <jbeulich@suse.com>; Andrew Cooper
> <Andrew.Cooper3@citrix.com>; Wei Liu <wl@xen.org>
> 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@citrix.com>
> > > Sent: 21 August 2019 15:59
> > > To: xen-devel@lists.xenproject.org
> > > Cc: Roger Pau Monne <roger.pau@citrix.com>; Paul Durrant <Paul.Durrant@citrix.com>; Jan Beulich
> > > <jbeulich@suse.com>; Andrew Cooper <Andrew.Cooper3@citrix.com>; Wei Liu <wl@xen.org>
> > > 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-08-22 8:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 14:58 [Xen-devel] [PATCH 0/7] ioreq: add support for internal servers Roger Pau Monne
2019-08-21 14:58 ` [Xen-devel] [PATCH 1/7] ioreq: add fields to allow internal ioreq servers Roger Pau Monne
2019-08-21 14:58 ` [Xen-devel] [PATCH 2/7] ioreq: add internal ioreq initialization support Roger Pau Monne
2019-08-21 16:24 ` Paul Durrant
2019-08-22 7:23 ` Roger Pau Monné
2019-08-22 8:30 ` Paul Durrant
2019-08-21 14:58 ` [Xen-devel] [PATCH 3/7] ioreq: allow dispatching ioreqs to internal servers Roger Pau Monne
2019-08-21 16:29 ` Paul Durrant
2019-08-22 7:40 ` Roger Pau Monné
2019-08-22 8:33 ` Paul Durrant
2019-08-21 14:59 ` [Xen-devel] [PATCH 4/7] ioreq: allow registering internal ioreq server handler Roger Pau Monne
2019-08-21 16:35 ` Paul Durrant
2019-08-22 7:43 ` Roger Pau Monné
2019-08-22 8:38 ` Paul Durrant [this message]
2019-08-21 14:59 ` [Xen-devel] [PATCH 5/7] ioreq: allow decoding accesses to MMCFG regions Roger Pau Monne
2019-08-21 14:59 ` [Xen-devel] [PATCH 6/7] vpci: register as an internal ioreq server Roger Pau Monne
2019-08-21 14:59 ` [Xen-devel] [PATCH 7/7] ioreq: provide support for long-running operations Roger Pau Monne
2019-08-22 9:15 ` Paul Durrant
2019-08-22 12:55 ` Roger Pau Monné
2019-08-22 13:07 ` Paul Durrant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5ac6988a64d14239935a8f7acace5d15@AMSPEX02CL03.citrite.net \
--to=paul.durrant@citrix.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).