On Wed, Sep 02, 2015 at 09:21:26AM +0200, Baptiste Reynal wrote: > On Tue, Sep 1, 2015 at 5:52 PM, Christoffer Dall > <christoffer.dall@xxxxxxxxxx> wrote: > > On Tue, Sep 01, 2015 at 05:32:21PM +0200, Baptiste Reynal wrote: > >> Hi everyone, > >> > >> The usefullness of this patch has already been discussed during the > >> first releases (http://lists.linuxfoundation.org/pipermail/iommu/2014-August/009586.html). > >> I underline the fact that it avoids implementing the logic on the > >> userspace program, as VFIO can be used for many usage (userspace > >> drivers and device assignment). > >> > >> If you're interested in the implementation on the userspace side, an > >> RFC has been suggested for QEMU: > >> http://lists.gnu.org/archive/html/qemu-devel/2015-01/msg01211.html > > > > This one-year-old discussion is hardly exhaustive. > > > > I think you missed the gist of the question for Eric a bit as well. > > > > One important question for me is whether seeing the host DT is always > > sufficient or if the kernel and physical device driver can have more > > information about the device and its configuration which userspace may > > need, which cannot be directly read in the DT (for example because the > > driver has initialized the device in a specific way). My point is, it's > > really not about DT-specific things (what if you used ACPI?), but it's > > about retrieving properties of a device and its configuration from > > userspace. > > > > Have we thought about the possible ways to achieve this and weight one > > option against the other? > > Problem is that now we only have a very few platform devices behind an > IOMMU, so we don't have the visibility to know if such a case will > occur. With the current use cases, the interface seems to be > sufficient. Ideally we can think about future use cases based on the experience of people in the community and come up with a solution considering future use cases. > By using IOCTL, we can always change the implementation > later without any change on the userspace. Can you be more concrete with what you mean here? > > Do you think we can valid the API, then if such a case occurs (when > the device informations changes between the device tree and the > running state) we can change the kernel implementation ? > Sorry, I don't understand this paragraph. -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
