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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
