On Wed, Sep 2, 2015 at 12:32 PM, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote: > 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? Currently not, only OF and ACPI properties are read. > > -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
