Re: [PATCH] evtchn/Flask: pre-allocate node on send path

[Julien Grall <julien@xxxxxxx>]

Hi Jan,

On 25/09/2020 16:36, Jan Beulich wrote:
> On 25.09.2020 16:33, Julien Grall wrote:
> > On 25/09/2020 14:58, Jan Beulich wrote:
> > > On 25.09.2020 15:16, Julien Grall wrote:
> > > > Fair enough. I would still like to consider a way where we could avoid
> > > > to hack xsm_* because we have the interrupts disabled.
> > > Well, from a conceptual pov it's at least questionable for XSM to
> > > need any memory allocations at all when merely being asked for
> > > permission. And indeed the need for it arises solely from its
> > > desire to cache the result, for the sake of subsequent lookups.
> > >
> > > I also find it odd that there's an XSM check on the send path in
> > > the first place. This isn't just because it would seem to me that
> > > it should be decided at binding time whether sending is permitted
> > > - I may easily be missing something in the conceptual model here.
> > > It's also because __domain_finalise_shutdown() too uses
> > > evtchn_send(), and I didn't think this one should be subject to
> > > any XSM check (just like send_guest_*() aren't).
> > Maybe this is the first question we need to answer?
> Indeed that was the question I asked myself before putting together
> the patch. Yet I have no idea who could answer it, with Daniel
> having gone silent for quite long a time now. Hence I didn't even
> put up the question, but instead tried to find a halfway reasonable
> solution. 
IIRC, XSM is used by OpenXT and QubeOS. So I have CCed them to get some 
input.
> After all it's not just the master branch which is stuck
> right now.
> And from a backporting perspective having the "fix"
> touch code which hasn't had much churn over the last years may even
> be beneficial.
Right, but dropping xsm_evtchn_send() (if it is not possible) is going 
to be even better. So lets explore this solution first.
> Plus, as said, the minimal change of making Flask
> avoid xmalloc() when IRQs are off is a change that ought to be made
> anyway imo, in order to favor proper functioning over performance.
If there are other use, then yes. What I don't like in the current 
approach is we are hijacking xsm_event_send() for pre-allocating memory.
Cheers,

--
Julien Grall