Re: [Qemu-devel] [PATCH qemu v8 02/14] vfio: spapr: Move SPAPR-related code to a separate file

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 06/19/2015 07:10 AM, Alex Williamson wrote:
> On Thu, 2015-06-18 at 21:37 +1000, Alexey Kardashevskiy wrote:
>> This moves SPAPR bits to a separate file to avoid pollution of x86 code.
>>
>> This enables spapr-vfio on CONFIG_SOFTMMU (not CONFIG_PSERIES) as
>> the config options are only visible in makefiles and not in the source code
>> so there is no an obvious way of implementing stubs if hw/vfio/spapr.c is
>> not compiled.
>>
>> This is a mechanical patch.
>
>
> Why does spapr code always need to be pulled out of common code and
> private interfaces exposed to be called in ad-hock ways?  Doesn't that
> say something about a lack of design in the implementation?  Why not
> also pull out type1 support and perhaps create an interface between vfio
> common code and vfio iommu code?

But how exactly? A container_ops struct with 2 callbacks: 
init_listener()/ioctl(), per IOMMU type? vfio_container_ioctl() does not do 
anything spapr-specific (its existance is spapr-specific though). And I 
will still have to expose vfio_dma_map()/vfio_dma_unmap() to these new 
spapr.c and type1.c (move these map/unmap helpers to common_api.c?).

And then I'll be told to make a container an QOM object, with class and 
state. btw why are not they all QOM-ed already? :)

And I also need to expose ioctl(vfio_kvm_device_fd,...) but it does not 
belong to container.

Most likely other IOMMUs will look pretty much the same as TYPE1, ours is 
just really weird (is there any other arch exposing IOMMU ot the guest?).



-- 
Alexey