qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 2/4] vfio: VFIO driver for mediated devices


From: Jike Song
Subject: Re: [Qemu-devel] [PATCH v7 2/4] vfio: VFIO driver for mediated devices
Date: Wed, 21 Sep 2016 11:19:17 +0800
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

On 09/21/2016 12:24 AM, Alex Williamson wrote:
> On Tue, 20 Sep 2016 10:50:47 +0800
> Jike Song <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]