[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics



>>> On 21.06.17 at 16:38, <george.dunlap@xxxxxxxxxx> wrote:
> On 21/06/17 11:08, Jan Beulich wrote:
>> So far callers of the libxc interface passed in a domain ID which was
>> then ignored in the hypervisor. Instead, make the hypervisor honor it
>> (accepting DOMID_INVALID to obtain original behavior), allowing to
>> query whether a device is assigned to a particular domain. Ignore the
>> passed in domain ID at the libxc layer instead, in order to not break
>> existing callers. New libxc functions would need to be added if callers
>> wanted to leverage the new functionality.
> 
> I don't think your modified description matches the name of the call at all.
> 
> It looks like the callers expect "test_assign_device" to answer the
> question: "Can I assign a device to this domain"?

I don't think so - the question being answered by the original
operation is "Is this device assigned to any domain?" with the
implied inverse "Is this device available to be assigned to some
domain (i.e. it is currently unassigned or owned by Dom0)?"

> It looks like it's meant to be used in XSM environments, to allow a
> policy to permit or forbid specific guests to have access to specific
> devices.  On a default (non-XSM) system, the answer to that question
> doesn't depend on the domain it's being assigned to, but only whether
> the device is already assigned to another domain; but on XSM systems the
> logic can presumably be more complicated.
> 
> That sounds like a perfectly sane semantic to me, and this patch removes
> that ability.

And again I don't think so: Prior to the patch, do_domctl() at its
very top makes sure to entirely ignore the passed in domain ID.
This code sits ahead of the XSM check, so XSM has no way of
knowing which domain has been specified by the caller.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.