[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 2/5] xen: make evtchn_alloc_unbound public
- To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
- From: Julien Grall <julien@xxxxxxx>
- Date: Mon, 28 Mar 2022 15:56:19 +0100
- Cc: Jan Beulich <jbeulich@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, jgross@xxxxxxxx, Bertrand.Marquis@xxxxxxx, Volodymyr_Babchuk@xxxxxxxx, Luca Miccio <lucmiccio@xxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "Daniel P. Smith" <dpsmith.dev@xxxxxxxxx>
- Delivery-date: Mon, 28 Mar 2022 14:56:26 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Hi Stefano,
On 25/03/2022 21:05, Stefano Stabellini wrote:
On Fri, 25 Mar 2022, Julien Grall wrote: > As a contributor, sadly I won't be
able to spend a lot of time on this
in the following months. If a significant rework is required, I don't
think I'll be able to do it, at least not for this Xen release (and it
would be nice to have dom0less PV drivers in the coming release.) If
Daniel is willing, I could add his "idle_domain is_priv" patch to this
series. Not as clean as a proper constructor domain but it would work
and it would be simple. It could be evolved into a nicer constructor
domain later.
This is not my preference but I could do that if Julien and Jan prefer
this approach and if Daniel is happy to share his patch.
This is still my preference because we are avoiding to push the problem
to the unlucky person that will need to introduce another (or multiple)
'skip_xsm'.
AFAIU, your proposal is to duplicate code. This brings other risks such as
duplicated bug and more code to maintain.
Got it. I'll make one last attempt at a proposal that doesn't involve
the fake constructor domain. The goal is to avoid code duplication while
providing a safe way forward to make progress with only a small amount
of changes. What if we:
- rename evtchn_alloc_unbound to _evtchn_alloc_unbound (still static)
- add a skip_xsm parameter to _evtchn_alloc_unbound
- introduce a wrapper evtchn_alloc_unbound that always set skip_xsm to
false (same interface as today's evtchn_alloc_unbound)
- introduce an __init early_evtchn_alloc_unbound public function that
sets skip_xsm to true
This way:
- we have a single implementation in _evtchn_alloc_unbound (no code
duplication)
- the only function exposed that skips the XSM check is __init
- evtchn_alloc_unbound continue to have the XSM check same as today
E.g.:
static int _evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc, bool skip_xsm)
{
...
}
static int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
{
return _evtchn_alloc_unbound(alloc, false);
}
int __init early_evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
{
return _evtchn_alloc_unbound(alloc, true);
}
Would this be good enough for now?
I would be OK with that. Note that, I think we need to protect the use
of skip_xsm with evaluate_nospec().
Cheers,
--
Julien Grall
|