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 13:02:39 +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:51 PM, Alex Williamson wrote:
> On Wed, 21 Sep 2016 11:19:17 +0800
> Jike Song <address@hidden> wrote:
> 
>> 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?
> 
> Are you assuming that I'm suggesting using VFIO_PCI_OFFSET_TO_INDEX in
> the mdev core?  We've been through that, I've rejected it, that's not
> at all what I'm describing.  The vfio bus driver defines the region
> layout, but once defined it is fixed for a given device instance.  A
> user does not need to call ioctl(VFIO_DEVICE_GET_REGION_INFO) prior to
> every region access to make sure the region offsets haven't changed
> dynamically.  If it's fixed to the user than it's also fixed to the
> mdev core for a given device instance, so nothing prevents the core
> code from doing its own enumeration of the region offsets and sizes and
> caching them into data structures.  That has nothing whatsoever to do
> with vfio-pci and makes no assumptions about the layout of regions
> within device fd. Thanks,
> 

I misunderstood that previously and I understand the whole idea now.
Thanks for the kind explanation! :)

--
Thanks,
Jike




reply via email to

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