On 09/21/2016 12:24 AM, Alex Williamson wrote: > On Tue, 20 Sep 2016 10:50:47 +0800 > Jike Song <jike.song@xxxxxxxxx> wrote: /* trim the quotations */ >> Even performing a lightweight sanity check, would require vfio-mdev >> to be able to decode the ppos into a particular region, that means >> information of all regions should be stored in the framework. I guess >> it is not your preferred way :) > > There's certainly a trade-off there, we don't support dynamic regions, > the user expects them to be stable and the mdev-core code can expect > that also. It might simplify the vendor drivers slightly if the core > could perform such a basic sanity test, but the cost to do so would be > that the core needs to have an understanding of the region layout of > the device. I agree with why the requirement is, but I am suspicious that, if we assume the regions are stable, try to encode/decode that within the mdev-core framework - instead of vendor drivers - that is because we want mdev to be API compatible with vfio-pci? Being API compatible with vfio-pci is (IMHO) the most beautiful thing in current mdev design, but is it necessary to make it mandatory? How about letting the underlining vendor drivers to decide whether it is API compatible with vfio-pci, or will have a different set of userspace API? > That seems like non-trivial overhead to consolidate > testing that the vendor driver itself can do much more efficiently. Yes, this is also a trade-off if adopted :( -- Thanks, Jike -- 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
