[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
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |