On 03/09/2018 04:43 PM, Jan Beulich wrote: >>>> On 09.03.18 at 17:30, <george.dun...@citrix.com> wrote: >> On 03/09/2018 04:25 PM, Jan Beulich wrote: >>>>>> On 09.03.18 at 17:17, <o...@aepfle.de> wrote: >>>> --- a/xen/include/public/domctl.h >>>> +++ b/xen/include/public/domctl.h >>>> @@ -137,6 +137,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getdomaininfo_t); >>>> #define XEN_DOMCTL_PFINFO_BROKEN (0xdU<<28) /* broken page */ >>>> #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28) >>>> >>>> +#define XEN_GETPAGEFRAMEINFO3_MAX_SIZE 1024U >>> >>> This is an implementation detail; it shouldn't be made part of the >>> public interface. If there's a need for user land to know the value, >>> and if there's currently no way to query it, that's what you >>> would want to add. >> >> But the domctl interface isn't stable, right? There's no need to make a >> flexible backwards-compatible interface between libxc and Xen; sharing a >> #define should be fine, as long as there's only one place to change it. > > Well, strictly speaking this is an option. But I would prefer if we didn't > abuse the "is not a stable interface" property, which this changes > feels like it would. > > Furthermore it hasn't become clear to me why, if this hard coded > number is deemed a problem, we don't get rid of it altogether. > Domctl-s have long gained the ability to be preemptible - there > various examples.
Yes, making it preemptible and removing the limit is probably a better option. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
