[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.