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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.

> Also stub domains are allowed to rely on a stable
> interface, so I'm afraid a domctl is out of scope here anyway.
> It is bad enough that there are four domctl-s violating this
> rule (see xsm/dummy.h:xsm_domctl()).

OK, so then the fact that stubdomains (QEMU) use the non-stable domctl
is not intended, then it's fine to make it a physdevop.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel