[Top][All Lists]

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

Re: [Qemu-ppc] [PATCH qemu v8 02/14] vfio: spapr: Move SPAPR-related cod

From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [PATCH qemu v8 02/14] vfio: spapr: Move SPAPR-related code to a separate file
Date: Fri, 19 Jun 2015 10:16:34 +1000
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1

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?).


reply via email to

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