On Mon, Oct 5, 2015 at 11:53 AM, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote: > [why are you top-posting?] > > On Mon, Oct 05, 2015 at 11:42:38AM +0200, Baptiste Reynal wrote: >> In this patch series we want to wrap an already available kernel >> interface to expose a device property to userspace, > > which 'already available kernel interface' is that exactly? We use the unified device property interface. > >> in order to keep >> the code lighter on the userspace. We need those properties in VFIO as > > I'm not sure I agree with your 'need those properties in VFIO' statement > here, can you elaborate? > For device assignment, we need to transfer those properties to the guest in order to fully exploit the device (and not simply transfer generic properties for a given device). The example I have in mind is the PL330 which can have optionnal properties, as described in Documentation/devicetree/bindings/dma/arm-pl330.txt >> VFIO grants the possibility to develop userspace drivers. >> >> The sysfs doesn't seems to be ready for this kind of usage. We can >> only find raw data that require heavy parsing. Here we retrieve >> directly usable data and it can be extended later according to new >> needs (as it is already done with ACPI). > > Why couldn't you expose this kind of data through sysfs instead of VFIO > and independently of VFIO? Would that be more wrong/difficult/whatever? > This has been bound to VFIO as we needed it for VFIO, but I don't see any reasons not to expose it somewhere else if it may be reused. >> >> This interface has been developed for VFIO and is currently bound to >> it, though there is no special dependencies with it. We could make it >> more generic, but I can only think of VFIO to use it. > > Thanks, > -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
