>>> On 17.01.19 at 13:32, <roger....@citrix.com> wrote: > On Thu, Jan 17, 2019 at 05:20:18AM -0700, Jan Beulich wrote: >> >>> On 17.01.19 at 12:56, <roger....@citrix.com> wrote: >> > On Thu, Jan 17, 2019 at 04:52:42AM -0700, Jan Beulich wrote: >> >> >>> On 17.01.19 at 09:57, <roger....@citrix.com> wrote: >> >> > While not against using physdevop if we agree that a new hypercall is >> >> > the way to go, I would prefer a domctl because this hypercall would >> >> > only be used by toolstack components, and thus doesn't need to be >> >> > added to the public stable ABI available to all guests, even if the >> >> > functionality is actually limited to stubdomains. >> >> >> >> But a new sub-op doesn't need to be part of the stable ABI. >> >> See how e.g. various of the memory sub-ops are restricted to >> >> be used by the tool stack, and hence not required to remain >> >> unchanged. >> > >> > Oh, then I'm all in for a physdevop limited to stubdomain only usage. >> >> Hmm, stubdomain is different: How would you limit this in the >> header? > > Oh, I wasn't meaning to limit this in the header, but in the > implementation. Ie: by returning an error when called from > non-stubdomains. > > I don't see a reason to allow non-stubdomains to make use of this new > hypercall if it's not required, that would just expand the attack > surface for no good reason IMO.
Restricting it in the implementation is certainly fine, and indeed desirable. But the ABI stability guarantees are reflected by __XEN_TOOLS__ conditionals in the public headers. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
