From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9B1j-000638-DD for qemu-devel@nongnu.org; Thu, 29 Sep 2011 03:27:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R9B1h-00021H-Il for qemu-devel@nongnu.org; Thu, 29 Sep 2011 03:27:27 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:34814) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9B1h-00020x-4l for qemu-devel@nongnu.org; Thu, 29 Sep 2011 03:27:25 -0400 Message-ID: <4E841DDB.1000104@web.de> Date: Thu, 29 Sep 2011 09:27:23 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1317278706-16105-1-git-send-email-david@gibson.dropbear.id.au> <1317278706-16105-4-git-send-email-david@gibson.dropbear.id.au> In-Reply-To: <1317278706-16105-4-git-send-email-david@gibson.dropbear.id.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC87AFED019FEC71D5C601B35" Sender: jan.kiszka@web.de Subject: Re: [Qemu-devel] [PATCH 3/3] pseries: Use Book3S-HV TCE acceleration capabilities List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: agraf@suse.de, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC87AFED019FEC71D5C601B35 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2011-09-29 08:45, David Gibson wrote: > The pseries machine of qemu implements the TCE mechanism used as a > virtual IOMMU for the PAPR defined virtual IO devices. Because the > PAPR spec only defines a small DMA address space, the guest VIO > drivers need to update TCE mappings very frequently - the virtual > network device is particularly bad. This means many slow exits to > qemu to emulate the H_PUT_TCE hypercall. >=20 > Sufficiently recent kernels allow this to be mitigated by implementing > H_PUT_TCE in the host kernel. To make use of this, however, qemu > needs to initialize the necessary TCE tables, and map them into itself > so that the VIO device implementations can retrieve the mappings when > they access guest memory (which is treated as a virtual DMA > operation). >=20 > This patch adds the necessary calls to use the KVM TCE acceleration. > If the kernel does not support acceleration, or there is some other > error creating the accelerated TCE table, then it will still fall back > to full userspace TCE implementation. >=20 > Signed-off-by: David Gibson > --- > hw/spapr_vio.c | 8 ++++++- > hw/spapr_vio.h | 1 + > target-ppc/kvm.c | 54 ++++++++++++++++++++++++++++++++++++++++++= ++++++++ > target-ppc/kvm_ppc.h | 14 +++++++++++++ > 4 files changed, 76 insertions(+), 1 deletions(-) >=20 > diff --git a/hw/spapr_vio.c b/hw/spapr_vio.c > index 35818e1..1da3032 100644 > --- a/hw/spapr_vio.c > +++ b/hw/spapr_vio.c > @@ -165,7 +165,13 @@ static void rtce_init(VIOsPAPRDevice *dev) > * sizeof(VIOsPAPR_RTCE); > =20 > if (size) { > - dev->rtce_table =3D g_malloc0(size); > + dev->rtce_table =3D kvmppc_create_spapr_tce(dev->reg, > + dev->rtce_window_siz= e, > + &dev->kvmtce_fd); > + > + if (!dev->rtce_table) { > + dev->rtce_table =3D g_malloc0(size); > + } > } > } > =20 > diff --git a/hw/spapr_vio.h b/hw/spapr_vio.h > index 4fe5f74..a325a5f 100644 > --- a/hw/spapr_vio.h > +++ b/hw/spapr_vio.h > @@ -57,6 +57,7 @@ typedef struct VIOsPAPRDevice { > target_ulong signal_state; > uint32_t rtce_window_size; > VIOsPAPR_RTCE *rtce_table; > + int kvmtce_fd; > VIOsPAPR_CRQ crq; > } VIOsPAPRDevice; > =20 > diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c > index 37ee902..866cf7f 100644 > --- a/target-ppc/kvm.c > +++ b/target-ppc/kvm.c > @@ -28,6 +28,7 @@ > #include "kvm_ppc.h" > #include "cpu.h" > #include "device_tree.h" > +#include "hw/sysbus.h" > #include "hw/spapr.h" > =20 > #include "hw/sysbus.h" > @@ -58,6 +59,7 @@ static int cap_ppc_smt =3D 0; > #ifdef KVM_CAP_PPC_RMA > static int cap_ppc_rma =3D 0; > #endif > +static int cap_spapr_tce =3D false; > =20 > /* XXX We have a race condition where we actually have a level trigger= ed > * interrupt, but the infrastructure can't expose that yet, so the= guest > @@ -87,6 +89,9 @@ int kvm_arch_init(KVMState *s) > #ifdef KVM_CAP_PPC_RMA > cap_ppc_rma =3D kvm_check_extension(s, KVM_CAP_PPC_RMA); > #endif > +#ifdef KVM_CAP_SPAPR_TCE > + cap_spapr_tce =3D kvm_check_extension(s, KVM_CAP_SPAPR_TCE); > +#endif > =20 > if (!cap_interrupt_level) { > fprintf(stderr, "KVM: Couldn't find level irq capability. Expe= ct the " > @@ -792,6 +797,55 @@ off_t kvmppc_alloc_rma(const char *name) > #endif > } > =20 > +void *kvmppc_create_spapr_tce(target_ulong liobn, uint32_t window_size= , int *pfd) > +{ struct kvm_create_spapr_tce args =3D { Missing newline? And please make sure your patches pass checkpatch.pl. Jan --------------enigC87AFED019FEC71D5C601B35 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EHdsACgkQitSsb3rl5xRDqACg1toT9eVcKMi97B4UZ0TOO+Wu n5kAoJLxakiZd5yeWcYqZGCPLk9u4ig+ =YhfG -----END PGP SIGNATURE----- --------------enigC87AFED019FEC71D5C601B35--