qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 18/18] vfio: Enable in-kernel acceleration vi


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH v4 18/18] vfio: Enable in-kernel acceleration via VFIO KVM device
Date: Wed, 18 Feb 2015 10:56:41 +1100
User-agent: Mutt/1.5.23 (2014-03-12)

On Tue, Feb 17, 2015 at 01:36:38PM +1100, Alexey Kardashevskiy wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 02/05/2015 03:49 PM, David Gibson wrote:
> > On Thu, Jan 29, 2015 at 08:27:30PM +1100, Alexey Kardashevskiy wrote:
> >> TCE hypercalls (H_PUT_TCE, H_PUT_TCE_INDIRECT, H_STUFF_TCE) use a
> >> logical bus number (LIOBN) to identify which TCE table the request
> >> is addressed to. However VFIO kernel driver operates with IOMMU
> >> group IDs and has no idea about which LIOBN corresponds to which
> >> group. If the host kernel supports in-kernel acceleration for TCE
> >> calls, we have to provide the LIOBN to IOMMU mapping information.
> >> 
> >> This makes use of a VFIO KVM device's 
> >> KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN attribute to set the link 
> >> between LIOBN and IOMMU group.
> >> 
> >> The vfio_container_spapr_set_liobn() helper is implemented
> >> completely in vfio.c because kvm_vfio_spapr_tce_liobn needs a group
> >> fd and we do not want to share resources likes that outside vfio.c.
> > 
> > I thought you'd moved away from the idea of in-kernel TCE 
> > acceleration, since big DMA windows made it unnecessary.
> 
> 
> Not entirely. DDW may not be supported by some hardware (like nVidia
> being able to generate only 40bit DMA addresses without hacks). DMA
> memory registering is pretty much about it - when we preregister pages,
> the KVM acceleration becomes lot simpler as it does not have to take care
> of pinning or locked_vm accounting.

Ok, that makes sense.

> But I should have not posted it here anyway, too early :)


> >> Signed-off-by: Alexey Kardashevskiy <address@hidden> --- 
> >> hw/ppc/spapr_iommu.c    |  1 + hw/ppc/spapr_pci_vfio.c | 11
> >> +++++++++++ hw/vfio/common.c        | 33
> >> +++++++++++++++++++++++++++++++++ include/hw/vfio/vfio.h  |  4 ++++ 
> >> 4 files changed, 49 insertions(+)
> >> 
> >> diff --git a/hw/ppc/spapr_iommu.c b/hw/ppc/spapr_iommu.c index
> >> 258f837..3de95d7 100644 --- a/hw/ppc/spapr_iommu.c +++
> >> b/hw/ppc/spapr_iommu.c @@ -142,6 +142,7 @@ static int
> >> spapr_tce_table_realize(DeviceState *dev) if (!tcet->table) { size_t
> >> table_size = tcet->nb_table * sizeof(uint64_t); tcet->table =
> >> g_malloc0(table_size); +        tcet->vfio_accel = false;
> > 
> > This should probably have a qdev prop so that it can be explicitly 
> > disabled on a per-device basis for testing.
> 
> 
> It is a TCE table's property, how can you disable it if it is not created
> via the command line?

Uh, yeah it would have to be a property on VIO devices and on VFIO
host bridges which the propagates the option to the TCE table.

Hrm, that does sound a bit messy now I think about it.

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


reply via email to

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