[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 4/4] xen/x86: Allow stubdom access to irq created for msi.
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |