[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] evtchn: make support for different ABIs tunable
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Wed, 7 Aug 2019 16:30:08 +0200
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Eslam Elnikety <elnikety@xxxxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, David Woodhouse <dwmw@xxxxxxxxxxxx>
- Delivery-date: Wed, 07 Aug 2019 14:30:13 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 07.08.2019 15:41, Andrew Cooper wrote:
On 07/08/2019 12:20, Eslam Elnikety wrote:
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 19486d5e32..654b4fdd22 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -64,6 +64,9 @@ struct xen_domctl_createdomain {
/* Is this a xenstore domain? */
#define _XEN_DOMCTL_CDF_xs_domain 4
#define XEN_DOMCTL_CDF_xs_domain (1U<<_XEN_DOMCTL_CDF_xs_domain)
+ /* Disable FIFO event channels? */
+#define _XEN_DOMCTL_CDF_disable_fifo 5
+#define XEN_DOMCTL_CDF_disable_fifo (1U<<_XEN_DOMCTL_CDF_disable_fifo)
uint32_t flags;
On the subject of the the patch itself, I think this is broadly the
right principle, but wants to be expressed differently.
First, you'll want to rebase onto a very recent master, and specifically
over c/s d8f2490561eb which has changed how this field is handled in Xen.
Furthermore, if there is this problem for event channels, then there is
almost certainly a related problem for grant tables.
The control in Xen should be expressed in a positive form, or the logic
will become a tangle. It should be a bit permitting the use of the FIFO
ABI, rather than a bit saying "oh actually, you can't use that".
That said, it might be easier to declare FIFO to be "event channel v2",
and specify max_{grant,evntchn}_ver instead.
I'm not sure assuming linear (or actually any) ordering between
variants is a good thing. Yes, right now we only have gnttab
v1 and v2 and evtchn 2l and fifo, which could be considered v1
and v2 as you suggest. However, assuming a 3rd variant surfaces,
why would it be that one has to expose v2 just to make v3
usable? In particular gnttab v2 has various issues (which is why
you introduced a way to disable its use in the first place), yet
I'd hope we'd end up with a less quirky v3 if one ever becomes
necessary. And in turn I'd hope we could hide v2 from any v3
users.
IOW I think a bitmap to permit use of "advanced" versions is
more future proof. (As a side note, I don't think we want to
introduce a disable for the respective v1 interfaces.)
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
