On 8/12/2016 12:13 AM, Alex Williamson wrote: > > TBH, I don't see how providing a default implementation of > validate_map_request() is useful. How many mediated devices are going > to want to identity map resources from the parent? Even if they do, it > seems we can only support a single mediated device per parent device > since each will map the same parent resource offset. Let's not even try > to define a default. If we get a fault and the vendor driver hasn't > provided a handler, send a SIGBUS. I expect we should also allow > vendor drivers to fill the mapping at mmap() time rather than expecting > this map on fault scheme. Maybe the mid-level driver should not even be > interacting with mmap() and should let the vendor driver entirely > determine the handling. > Should we go ahead with pass through mmap() call to vendor driver and let vendor driver decide what to do in mmap() call, either remap_pfn_range in mmap() or do fault on access and handle the fault in their driver. In that case we don't need to track mappings in mdev core. Let vendor driver do that on their own, right? > For the most part these mid-level drivers, like mediated pci, should be > as thin as possible, and to some extent I wonder if we need them at > all. We mostly want user interaction with the vfio device file > descriptor to pass directly to the vendor driver and we should only be > adding logic to the mid-level driver when it actually provides some > useful and generic simplification to the vendor driver. Things like > this default fault handling scheme don't appear to be generic at all, > it's actually a very unique use case I think. For the most part > I think the mediated interface is just a shim to standardize the > lifecycle of a mediated device for management purposes, > integrate "fake/virtual" devices into the vfio infrastructure, > provide common page tracking, pinning and mapping services, but > the device interface itself should mostly just pass through the > vfio device API straight through to the vendor driver. Thanks, > > Alex > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
