From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45431) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsXNQ-0001v9-7S for qemu-devel@nongnu.org; Thu, 05 Jun 2014 09:06:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsXNJ-0006sT-0p for qemu-devel@nongnu.org; Thu, 05 Jun 2014 09:06:40 -0400 Message-ID: <53906B56.3080007@suse.de> Date: Thu, 05 Jun 2014 15:06:30 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1401947401-21329-1-git-send-email-aik@ozlabs.ru> <1401947401-21329-2-git-send-email-aik@ozlabs.ru> <5390119D.8040201@ozlabs.ru> In-Reply-To: <5390119D.8040201@ozlabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v7 1/4] spapr_iommu: Make in-kernel TCE table optional List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy , qemu-devel@nongnu.org Cc: Alex Williamson , qemu-ppc@nongnu.org, Gavin Shan On 05.06.14 08:43, Alexey Kardashevskiy wrote: > On 06/05/2014 03:49 PM, Alexey Kardashevskiy wrote: >> POWER KVM supports an KVM_CAP_SPAPR_TCE capability which allows allocating >> TCE tables in the host kernel memory and handle H_PUT_TCE requests >> targeted to specific LIOBN (logical bus number) right in the host without >> switching to QEMU. At the moment this is used for emulated devices only >> and the handler only puts TCE to the table. If the in-kernel H_PUT_TCE >> handler finds a LIOBN and corresponding table, it will put a TCE to >> the table and complete hypercall execution. The user space will not be >> notified. >> >> Upcoming VFIO support is going to use the same sPAPRTCETable device class >> so KVM_CAP_SPAPR_TCE is going to be used as well. That means that TCE >> tables for VFIO are going to be allocated in the host as well. >> However VFIO operates with real IOMMU tables and simple copying of >> a TCE to the real hardware TCE table will not work as guest physical >> to host physical address translation is requited. >> >> So until the host kernel gets VFIO support for H_PUT_TCE, we better not >> to register VFIO's TCE in the host. >> >> This adds a bool @kvm_accel flag to the sPAPRTCETable device telling >> that sPAPRTCETable should not try allocating TCE table in the host kernel. >> Instead, the table will be created in QEMU. >> >> This adds an kvm_accel parameter to spapr_tce_new_table() to let users >> choose whether to use acceleration or not. At the moment it is enabled >> for VIO and emulated PCI. Upcoming VFIO support will set it to false. >> >> Signed-off-by: Alexey Kardashevskiy >> --- >> >> This is a workaround but it lets me have one IOMMU device for VIO, emulated >> PCI and VFIO which is a good thing. >> >> The other way around would be a new KVM_CAP_SPAPR_TCE_VFIO capability but >> this needs kernel update. > > Never mind, I'll make it a capability. I'll post capability reservation > patch separately. Just rename the flag from "kvm_accel" to "vfio_accel", set it to true for vfio and false for emulated devices. Then the spapr_iommu file can check on the capability (and default to false for now, since it doesn't exist yet). That way you don't have to reserve a CAP today. Alex