Re: [Qemu-devel] [RFC v3 06/10] virt: Assign a VFIO platform device with -device option

[Eric Auger]

On 06/26/2014 11:25 AM, Alexander Graf wrote:
> 
> On 26.06.14 10:53, Eric Auger wrote:
>> On 06/25/2014 11:30 PM, Alexander Graf wrote:
>>> On 02.06.14 09:49, Eric Auger wrote:
>>>> This patch aims at allowing the end-user to specify the device he
>>>> wants to directly assign to his mach-virt guest in the QEMU command
>>>> line.
>>>>
>>>> The QEMU platform device becomes generic.
>>>>
>>>> Current choice is to reuse the "-device" option.
>>>>
>>>> For example when assigning Calxeda Midway xgmac device this option
>>>> is used:
>>>> -device vfio-platform,vfio_device="fff51000.ethernet",\
>>>> compat="calxeda/hb-xgmac",mmap-timeout-ms=1000
>>> I think we're walking into the right direction, but there is one major
>>> nit I have. I don't think we should have a -device vfio-platform. I
>>> think we should have a -device vfio-xgmac that maybe inherits from an
>>> abstrace vfio-platform class.
>>>
>>> That way machine code can assemble the device tree according to the
>>> device and you can also implement hardware specific hacks or
>>> dependencies if you need them - for example the MMIO masking to find an
>>> EOI you did earlier.
>> I must admit I am lacking experience of other devices than my dear
>> xgmac. I can just say that for the time beeing the approach seems to fit
>> some ARM Amba devices like PL330 DMA. We need to go further to identity
>> the limits of this generic approach.
> 
> No, I think we're better off not faking anything generic at all, because
> I'm 99.9% sure it will never be generic in real-world device cases.
> 
> And if we start doing things generically, people will soon want to have
> other mad additions to do device specific things in generic code, such
> as "take the device tree from the host, but modify property x, y and z".
> Better be clear about our limits from the beginning :).
> 
> Imagine vfio-platform as a transport, similar to TCP. We have ports and
> moving data from left to right is always the same, but whether you need
> to open 2 ports to get a working FTP data transfer is up to the
> implementation of the protocol above. Same thing here.
OK you convinced me. I will investigate that way then.
Eric
> 
> 
> Alex
>