On Wed, Sep 2, 2015 at 6:52 PM, Alex Williamson <alex.williamson@xxxxxxxxxx> wrote: > On Wed, 2015-09-02 at 11:49 +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. >> >> 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. > > I don't really like "ioctl" and "naive implementation" in the same > thought. The ioctl itself needs to be well thought out for current and > future needs, including independence from the source data type > (OF/DT/ACPI/etc), proven that it's necessary, it's not redundant to > existing interfaces, and vfio should be the one hosting it. Thanks, > The word we used, naive, does not mean a bad implementation of the IOCTL interface but rather it was referring to the fact that at this moment we export 1-to-1 the information available in the device tree via sys or proc file system. So one could obtain the same result without such interface, however our implementation is aready independent from the source of such information, since OF and ACPI are supported already, and there will be no problem in extending the interface to support more. The next release will take into account your comments about argsz and flags. Regards, Baptiste > Alex > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
