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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 22/06/17 11:58, Jan Beulich wrote:
>>> Option 2: Pass the domain to the XSM callback, enabling XSM / Flask
>>> policies that can forbid specific devices from being assigned to
>>> specific guests.
>>
>> Is there any possible downside to this ?
> 
> As soon as flask wouldn't ignore it anymore, there would be the risk
> of things currently working with a given XSM policy to stop working.
> Much depends on how consistent the test-assign and assign checks
> are (going to be) performed.
> 
>>> Any preferences?
>>
>> See above.  George's arguments make much more sense to me than Jan's,
>> in this thread.
> 
> Fine with me. Now as well as on past instances of looking at this,
> it simply didn't occur to me that the operation could be intended
> to work in the way George described. And in the end the patch
> will end up smaller with that alternative model. One last question
> then is whether retaining the original semantics with some special
> domain ID (DOMID_INVALID at present) is of any use.

I think test_assign_device should behave exactly as assign_device,
except that on success the device is not actually assigned.

The commit that introduced test_assign_device btw is 239ad70, "vt-d:
Test device assignability in xend, but defer actual assignment to
qemu-dm."  The obvious purpose was to be able to fail early if there was
going to be a failure.

In fact, there's probably an argument that the "test" functionality
should have been implemented by adding an extra flag, rather than an
extra hypercall.  Another approach would actually be to have the
test_assign_device and assign_device take exactly the same codepath,
except not finally do the assignment.  That would avoid any risk that
the two paths might get out of sync.

 -George

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