Re: [Xen-devel] [PATCH v2 4/4] xen/x86: Allow stubdom access to irq created for msi.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.01.19 at 13:32, <roger.pau@xxxxxxxxxx> wrote:
> On Thu, Jan 17, 2019 at 05:20:18AM -0700, Jan Beulich wrote:
>> >>> On 17.01.19 at 12:56, <roger.pau@xxxxxxxxxx> wrote:
>> > On Thu, Jan 17, 2019 at 04:52:42AM -0700, Jan Beulich wrote:
>> >> >>> On 17.01.19 at 09:57, <roger.pau@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel