Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
Il 27/05/2013 16:26, Alexey Kardashevskiy ha scritto: > On 05/27/2013 08:23 PM, Paolo Bonzini wrote: >> Il 25/05/2013 04:45, David Gibson ha scritto: > + case KVM_CREATE_SPAPR_TCE_IOMMU: { > + struct kvm_create_spapr_tce_iommu create_tce_iommu; > + struct kvm *kvm = filp->private_data; > + > + r = -EFAULT; > + if (copy_from_user(&create_tce_iommu, argp, > + sizeof(create_tce_iommu))) > + goto out; > + r = kvm_vm_ioctl_create_spapr_tce_iommu(kvm, > &create_tce_iommu); > + goto out; > + } >> >> Would it make sense to make this the only interface for creating TCEs? >> That is, pass both a window_size and an IOMMU group id (or e.g. -1 for >> no hardware IOMMU usage), and have a single ioctl for both cases? >> There's some duplicated code between kvm_vm_ioctl_create_spapr_tce and >> kvm_vm_ioctl_create_spapr_tce_iommu. > > Just few bits. Is there really much sense in making one function from those > two? I tried, looked a bit messy. Cannot really tell without the userspace bits. But ioctl proliferation is what the device and one_reg APIs were supposed to avoid... >> KVM_CREATE_SPAPR_TCE could stay for backwards-compatibility, or you >> could just use a new capability and drop the old ioctl. > > The old capability+ioctl already exist for quite a while and few QEMU > versions supporting it were released so we do not want just drop it. So > then what is the benefit of having a new interface with support of both types? > >> I'm not sure >> whether you're already considering the ABI to be stable for kvmppc. > > Is any bit of KVM using it? Cannot see from Documentation/ABI. I mean the userspace ABI (ioctls). Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] KVM: PPC: Add support for multiple-TCE hcalls
On 05/27/2013 08:08 PM, Paolo Bonzini wrote: > Il 21/05/2013 05:06, Alexey Kardashevskiy ha scritto: >> This adds real mode handlers for the H_PUT_TCE_INDIRECT and >> H_STUFF_TCE hypercalls for QEMU emulated devices such as virtio >> devices or emulated PCI. > > Do you mean vio? virtio (without getting into whether that's good or > bad) will bypass the iommu. yes, mistake, should be VIO. thanks! -- Alexey -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
On 05/27/2013 08:23 PM, Paolo Bonzini wrote: > Il 25/05/2013 04:45, David Gibson ha scritto: + case KVM_CREATE_SPAPR_TCE_IOMMU: { + struct kvm_create_spapr_tce_iommu create_tce_iommu; + struct kvm *kvm = filp->private_data; + + r = -EFAULT; + if (copy_from_user(&create_tce_iommu, argp, + sizeof(create_tce_iommu))) + goto out; + r = kvm_vm_ioctl_create_spapr_tce_iommu(kvm, &create_tce_iommu); + goto out; + } > > Would it make sense to make this the only interface for creating TCEs? > That is, pass both a window_size and an IOMMU group id (or e.g. -1 for > no hardware IOMMU usage), and have a single ioctl for both cases? > There's some duplicated code between kvm_vm_ioctl_create_spapr_tce and > kvm_vm_ioctl_create_spapr_tce_iommu. Just few bits. Is there really much sense in making one function from those two? I tried, looked a bit messy. > KVM_CREATE_SPAPR_TCE could stay for backwards-compatibility, or you > could just use a new capability and drop the old ioctl. The old capability+ioctl already exist for quite a while and few QEMU versions supporting it were released so we do not want just drop it. So then what is the benefit of having a new interface with support of both types? > I'm not sure > whether you're already considering the ABI to be stable for kvmppc. Is any bit of KVM using it? Cannot see from Documentation/ABI. -- Alexey -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
Il 25/05/2013 04:45, David Gibson ha scritto: >> >+ case KVM_CREATE_SPAPR_TCE_IOMMU: { >> >+ struct kvm_create_spapr_tce_iommu create_tce_iommu; >> >+ struct kvm *kvm = filp->private_data; >> >+ >> >+ r = -EFAULT; >> >+ if (copy_from_user(&create_tce_iommu, argp, >> >+ sizeof(create_tce_iommu))) >> >+ goto out; >> >+ r = kvm_vm_ioctl_create_spapr_tce_iommu(kvm, >> >&create_tce_iommu); >> >+ goto out; >> >+ } Would it make sense to make this the only interface for creating TCEs? That is, pass both a window_size and an IOMMU group id (or e.g. -1 for no hardware IOMMU usage), and have a single ioctl for both cases? There's some duplicated code between kvm_vm_ioctl_create_spapr_tce and kvm_vm_ioctl_create_spapr_tce_iommu. KVM_CREATE_SPAPR_TCE could stay for backwards-compatibility, or you could just use a new capability and drop the old ioctl. I'm not sure whether you're already considering the ABI to be stable for kvmppc. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] KVM: PPC: Add support for multiple-TCE hcalls
Il 21/05/2013 05:06, Alexey Kardashevskiy ha scritto: > This adds real mode handlers for the H_PUT_TCE_INDIRECT and > H_STUFF_TCE hypercalls for QEMU emulated devices such as virtio > devices or emulated PCI. Do you mean vio? virtio (without getting into whether that's good or bad) will bypass the iommu. Paolo > These calls allow adding multiple entries > (up to 512) into the TCE table in one call which saves time on > transition to/from real mode. > > This adds a tce_tmp cache to kvm_vcpu_arch to save valid TCEs > (copied from user and verified) before writing the whole list into > the TCE table. This cache will be utilized more in the upcoming > VFIO/IOMMU support to continue TCE list processing in the virtual > mode in the case if the real mode handler failed for some reason. > > This adds a guest physical to host real address converter > and calls the existing H_PUT_TCE handler. The converting function > is going to be fully utilized by upcoming VFIO supporting patches. > > This also implements the KVM_CAP_PPC_MULTITCE capability, > so in order to support the functionality of this patch, QEMU > needs to query for this capability and set the "hcall-multi-tce" > hypertas property only if the capability is present, otherwise > there will be serious performance degradation. > > Cc: David Gibson > Signed-off-by: Alexey Kardashevskiy > Signed-off-by: Paul Mackerras > > --- > Changelog: > * added kvm_vcpu_arch::tce_tmp > * removed cleanup if put_indirect failed, instead we do not even start > writing to TCE table if we cannot get TCEs from the user and they are > invalid > * kvmppc_emulated_h_put_tce is split to kvmppc_emulated_put_tce > and kvmppc_emulated_validate_tce (for the previous item) > * fixed bug with failthrough for H_IPI > * removed all get_user() from real mode handlers > * kvmppc_lookup_pte() added (instead of making lookup_linux_pte public) > --- > Documentation/virtual/kvm/api.txt | 14 ++ > arch/powerpc/include/asm/kvm_host.h |2 + > arch/powerpc/include/asm/kvm_ppc.h | 16 +- > arch/powerpc/kvm/book3s_64_vio.c| 118 ++ > arch/powerpc/kvm/book3s_64_vio_hv.c | 266 > +++ > arch/powerpc/kvm/book3s_hv.c| 39 + > arch/powerpc/kvm/book3s_hv_rmhandlers.S |6 + > arch/powerpc/kvm/book3s_pr_papr.c | 37 - > arch/powerpc/kvm/powerpc.c |3 + > include/uapi/linux/kvm.h|1 + > 10 files changed, 470 insertions(+), 32 deletions(-) > > diff --git a/Documentation/virtual/kvm/api.txt > b/Documentation/virtual/kvm/api.txt > index 5f91eda..3c7c7ea 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -2780,3 +2780,17 @@ Parameters: args[0] is the XICS device fd > args[1] is the XICS CPU number (server ID) for this vcpu > > This capability connects the vcpu to an in-kernel XICS device. > + > +6.8 KVM_CAP_PPC_MULTITCE > + > +Architectures: ppc > +Parameters: none > +Returns: 0 on success; -1 on error > + > +This capability enables the guest to put/remove multiple TCE entries > +per hypercall which significanly accelerates DMA operations for PPC KVM > +guests. > + > +When this capability is enabled, H_PUT_TCE_INDIRECT and H_STUFF_TCE are > +expected to occur rather than H_PUT_TCE which supports only one TCE entry > +per call. > diff --git a/arch/powerpc/include/asm/kvm_host.h > b/arch/powerpc/include/asm/kvm_host.h > index af326cd..85d8f26 100644 > --- a/arch/powerpc/include/asm/kvm_host.h > +++ b/arch/powerpc/include/asm/kvm_host.h > @@ -609,6 +609,8 @@ struct kvm_vcpu_arch { > spinlock_t tbacct_lock; > u64 busy_stolen; > u64 busy_preempt; > + > + unsigned long *tce_tmp;/* TCE cache for TCE_PUT_INDIRECT hall */ > #endif > }; > > diff --git a/arch/powerpc/include/asm/kvm_ppc.h > b/arch/powerpc/include/asm/kvm_ppc.h > index a5287fe..e852921b 100644 > --- a/arch/powerpc/include/asm/kvm_ppc.h > +++ b/arch/powerpc/include/asm/kvm_ppc.h > @@ -133,8 +133,20 @@ extern int kvmppc_pseries_do_hcall(struct kvm_vcpu > *vcpu); > > extern long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm, > struct kvm_create_spapr_tce *args); > -extern long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn, > - unsigned long ioba, unsigned long tce); > +extern struct kvmppc_spapr_tce_table *kvmppc_find_tce_table( > + struct kvm_vcpu *vcpu, unsigned long liobn); > +extern long kvmppc_emulated_validate_tce(unsigned long tce); > +extern void kvmppc_emulated_put_tce(struct kvmppc_spapr_tce_table *tt, > + unsigned long ioba, unsigned long tce); > +extern long kvmppc_virtmode_h_put_tce(struct kvm_vcpu *vcpu, > + unsigned long liobn, unsigned long ioba, > + unsigned long tce); > +extern long kvmppc_virtmode_h_put_tce_indirect(struct kvm_vcpu *vcpu, > + unsigned long liobn,