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

Re: [Xen-devel] [PATCH] evtchn: make support for different ABIs tunable

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

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.)


Xen-devel mailing list



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