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
pgpX9nOaWnLsp.pgp
Description: PGP signature
