Re: [Qemu-devel] [RFC PATCH 08/10] spapr_iommu: Rename vfio_accel parameter

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]

On Thu, Sep 17, 2015 at 10:54:38AM -0600, Alex Williamson wrote:
> On Thu, 2015-09-17 at 23:09 +1000, David Gibson wrote:
> > The vfio_accel parameter used when creating a new TCE table (guest IOMMU
> > context) has a confusing name.  What it really means is whether we need the
> > TCE table created to be able to support VFIO devices.
> > 
> > VFIO is relevant, because when available we use in-kernel acceleration of
> > the TCE table, but that may not work with VFIO devices because updates to
> > the table are handled in kernel, bypass qemu and so don't hit qemu's
> > infrastructure for keeping the VFIO host IOMMU state in sync with the guest
> > IOMMU state.
> > 
> > Rename the parameter to "need_vfio" throughout.  This is a cosmetic change,
> > with no impact on the logic.
> > There's a capability
> 
> nit, why entangle the technology you're using, vfio, with the feature
> you want, visible iommu updates?  You could rename this to something
> even more self describing, like disable_in_kernel_updates, or whatever
> more concise name you can come up with.

Because vfio availability really is the feature I want.  If the kernel
gains the ability to wire up the KVM TCE acceleration with VFIO (which
I believe is in IBM's plans), then the idea is that
spapr_tce_new_table() will return an accelerated table, even when VFIO
is requested.

Same thing with spapr_tce_need_vfio().

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]