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. By using IOCTL, we can always change the implementation later without any change on the userspace. 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 ? > > -Christoffer > >> >> On Tue, Sep 1, 2015 at 11:28 AM, Christoffer Dall >> <christoffer.dall@xxxxxxxxxx> wrote: >> > Hi Eric, >> > >> > On Tue, Sep 01, 2015 at 09:31:56AM +0200, Eric Auger wrote: >> > >> > [...] >> > >> >> >>> Can you reiterate why QEMU and VFIO don't already have the information >> >> >>> necessary to setup resources and present a DT to the guest that the >> >> >>> guest can use? >> >> >> A vfio-platform driver was bound to the passthrough'ed device. QEMU >> >> >> current knows the compat string of the device and the node's name and >> >> >> that's it. >> >> >> >> >> >> The VFIO platform driver currently does not allow to return device >> >> >> specific information. It just returns generic info such as resource >> >> >> info. The driver is HW agnostic. >> >> >> >> >> >> >> >> >> The QEMU VFIO device should be able to check some characteristics of the >> >> >> host device tree. Typically if the host node does not comply with some >> >> >> constraints it may not be possible to assign the device. >> >> >> >> >> >> We do not want the QEMU end-user to have in-depth knowledge of the HW so >> >> >> passing the info in the QEMU command line does not sound to be the good >> >> >> solution. >> >> >> >> >> >> >> >> >> As you mentioned /proc/device-tree depends on kernel option. I am able >> >> >> to find the properties in sysfs too but can we systematically rely on >> >> >> sysfs (CONFIG_SYSFS)? Also I would have expected the values to be human >> >> >> readable but they are not. Currently investigating open/read from qemu >> >> >> but is better than an ioctl API? ... >> >> >> >> >> > Yeah it does, but I thought we originally planned that the driver for a >> >> > specific platform device in QEMU should know these details, >> >> Yes that's the objective to put this intelligence in the QEMU VFIO >> >> device or more precisely in the associated function that builds its >> >> guest dt node. >> >> >> >> Let's take an example. Assuming an xgmac supports different speeds, you >> >> need to set those on guest. Either you put arbitrary values or you reuse >> >> the values that were set on host. Typically some values may not be >> >> supported by the HW. >> >> >> > >> > I see. I'm no expert here, but I could imagine that drivers could >> > overwrite some things in the DT or do some advanced probing of the >> > hardware which is then only exported in the sysfs and not the DT, so I >> > would go the sysfs approach myself. >> > >> >> Idea of genericity was ruled out indeed meaning each device needs to >> >> have a specialized QEMU VFIO device and an associated dt node creation >> >> function. Now this does not prevent from exploiting host dt information. >> >> Does that make sense? >> >> >> > Yes, thanks for the explanation. >> > >> > -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
