[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [RFC PATCH 08/10] spapr_iommu: Rename vfio_accel paramete
From: |
David Gibson |
Subject: |
Re: [Qemu-ppc] [RFC PATCH 08/10] spapr_iommu: Rename vfio_accel parameter |
Date: |
Fri, 18 Sep 2015 09:34:36 +1000 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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
pgp1CM4Gs58zB.pgp
Description: PGP signature
- Re: [Qemu-ppc] [RFC PATCH 06/10] vfio: Allow hotplug of containers onto existing guest IOMMU mappings, (continued)
Re: [Qemu-ppc] [RFC PATCH 06/10] vfio: Allow hotplug of containers onto existing guest IOMMU mappings, Laurent Vivier, 2015/09/23
[Qemu-ppc] [RFC PATCH 10/10] spapr_pci: Allow VFIO devices to work on the normal PCI host bridge, David Gibson, 2015/09/17
[Qemu-ppc] [RFC PATCH 04/10] vfio: Record host IOMMU's available IO page sizes, David Gibson, 2015/09/17
[Qemu-ppc] [RFC PATCH 08/10] spapr_iommu: Rename vfio_accel parameter, David Gibson, 2015/09/17
Re: [Qemu-ppc] [RFC PATCH 00/10] pseries: Allow VFIO devices on spapr-pci-host-bridge, Alex Williamson, 2015/09/17
Re: [Qemu-ppc] [Qemu-devel] [RFC PATCH 00/10] pseries: Allow VFIO devices on spapr-pci-host-bridge, Thomas Huth, 2015/09/23
Re: [Qemu-ppc] [RFC PATCH 00/10] pseries: Allow VFIO devices on spapr-pci-host-bridge, Laurent Vivier, 2015/09/23