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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

George Dunlap writes ("Re: [PATCH] passthrough: give 
XEN_DOMCTL_test_assign_device more sane semantics"):
> Well, I'm not sure what to say, because in my view the log message
> supports my view. :-)  Note that there are two errors, both explaining
> why the domain cannot be assigned -- one is "no IOMMU", one is "already
> assigned to a different guest".
> Yes, at the moment it doesn't have a separate message for -EPERM (which
> is presumably what XSM would return if there were some other problem).
> But it also doesn't correctly report other potential errors: -ENODEV if
> you try to assign a DT device on a PCI-based system, or a PCI device on
> a DT-based system.

The way I would put this is: The log message generation logic is
wrong, in that it sometimes lies.

>  (Apparently we also retirn -EINVAL if you included
> inappropriate flags, *or* if the device didn't exist, *or* if the device
> was already assigned somehwere else.  As long as we're re-painting
> things we should probably change this as well.)

This is quite unhelpful, indeed.

> I suggest we ask the toolstack maintainers what kind of a function they
> think would be most useful, and then we can implement that.
> 
> So, Wei and Ian (and Daniel if you're around):

After having reread the thread I still don't understand why Jan thinks
the ignored argument is a problem per so.  Ignored arguments are often
provided to ease future expansion (whether there is an ABI stability
guarantee or not).

In this case I think that the domid is not passed to the XSM check is
simply a bug.  I don't know if that can be fixed easily.

> 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 ?

> Any preferences?

See above.  George's arguments make much more sense to me than Jan's,
in this thread.

Ian.

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