On Wed, Sep 02, 2015 at 11:49:12AM +0200, Baptiste Reynal wrote: > On Wed, Sep 2, 2015 at 11:21 AM, Christoffer Dall > <christoffer.dall@xxxxxxxxxx> wrote: > > 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? > > > > By using an IOCTL, we define an API that allows to retrieve device > properties from userspace. The way it is retrieved is handled by the > kernel (For example for now if OF is unavailable, the kernel will > retrieve the property using ACPI) and is totally transparent from the > userspace point of view. ok, I thought that this series was targeting device tree specifically, but I see that you changed this approach in v3. > > My point is that we can go with the current naive implementation for > now, and we might extend it later according to the needs of future > devices, without changing anything from the userspace point of view. > fair enough. Is this series exporting properties not already exported through sysfs? -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
