From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfk7F-00017b-Ke for qemu-devel@nongnu.org; Mon, 20 Feb 2017 04:18:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cfk7C-0001sU-A1 for qemu-devel@nongnu.org; Mon, 20 Feb 2017 04:18:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49840) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cfk7C-0001sA-0s for qemu-devel@nongnu.org; Mon, 20 Feb 2017 04:18:38 -0500 References: <1484026704-28027-1-git-send-email-mst@redhat.com> <1484026704-28027-9-git-send-email-mst@redhat.com> <60ec34e3-2585-123f-7bc0-9d7bb143fc38@redhat.com> From: Jason Wang Message-ID: Date: Mon, 20 Feb 2017 17:18:23 +0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PULL 08/41] intel_iommu: support device iotlb descriptor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Liu, Yi L" , "Michael S. Tsirkin" , "qemu-devel@nongnu.org" Cc: "Lan, Tianyu" , Peter Maydell , "Tian, Kevin" , Eduardo Habkost , Peter Xu , Alex Williamson , Paolo Bonzini , Richard Henderson On 2017=E5=B9=B402=E6=9C=8820=E6=97=A5 17:13, Liu, Yi L wrote: >> -----Original Message----- >> From: Jason Wang [mailto:jasowang@redhat.com] >> Sent: Monday, February 20, 2017 5:04 PM >> To: Liu, Yi L ; Michael S. Tsirkin ; qemu- >> devel@nongnu.org >> Cc: Lan, Tianyu ; Peter Maydell >> ; Tian, Kevin ; Eduard= o >> Habkost ; Peter Xu ; Alex >> Williamson ; Paolo Bonzini >> ; Richard Henderson >> Subject: Re: [Qemu-devel] [PULL 08/41] intel_iommu: support device iot= lb >> descriptor >> >> >> >> On 2017=E5=B9=B402=E6=9C=8820=E6=97=A5 16:27, Liu, Yi L wrote: >>>> -----Original Message----- >>>> From: Jason Wang [mailto:jasowang@redhat.com] >>>> Sent: Friday, February 17, 2017 2:43 PM >>>> To: Liu, Yi L ; Michael S. Tsirkin >>>> ; qemu- devel@nongnu.org >>>> Cc: Peter Maydell ; Eduardo Habkost >>>> ; Peter Xu ; Paolo Bonzini >>>> ; Richard Henderson ; Tian, >>>> Kevin ; Lan, Tianyu ; >>>> Alex Williamson >>>> Subject: Re: [Qemu-devel] [PULL 08/41] intel_iommu: support device >>>> iotlb descriptor >>>> >>>> >>>> >>>> On 2017=E5=B9=B402=E6=9C=8817=E6=97=A5 14:18, Liu, Yi L wrote: >>>>>> -----Original Message----- >>>>>> From: Jason Wang [mailto:jasowang@redhat.com] >>>>>> Sent: Thursday, February 16, 2017 1:44 PM >>>>>> To: Liu, Yi L ; Michael S. Tsirkin >>>>>> ; qemu- devel@nongnu.org >>>>>> Cc: Peter Maydell ; Eduardo Habkost >>>>>> ; Peter Xu ; Paolo Bonzini >>>>>> ; Richard Henderson ; Tian, >>>>>> Kevin ; Lan, Tianyu ; >>>>>> Alex Williamson >>>>>> Subject: Re: [Qemu-devel] [PULL 08/41] intel_iommu: support device >>>>>> iotlb descriptor >>>>>> >>>>>> >>>>>> >>>>>> On 2017=E5=B9=B402=E6=9C=8816=E6=97=A5 13:36, Liu, Yi L wrote: >>>>>>>> -----Original Message----- >>>>>>>> From: Qemu-devel >>>>>>>> [mailto:qemu-devel-bounces+yi.l.liu=3Dintel.com@nongnu.org] >>>>>>>> On Behalf Of Michael S. Tsirkin >>>>>>>> Sent: Tuesday, January 10, 2017 1:40 PM >>>>>>>> To: qemu-devel@nongnu.org >>>>>>>> Cc: Peter Maydell ; Eduardo Habkost >>>>>>>> ; Jason Wang ; Peter >>>> Xu >>>>>>>> ; Paolo Bonzini ; Richar= d >>>>>>>> Henderson >>>>>>>> Subject: [Qemu-devel] [PULL 08/41] intel_iommu: support device >>>>>>>> iotlb descriptor >>>>>>>> >>>>>>>> From: Jason Wang >>>>>>>> >>>>>>>> This patch enables device IOTLB support for intel iommu. The >>>>>>>> major work is to implement QI device IOTLB descriptor processing >>>>>>>> and notify the device through iommu notifier. >>>>>>>> >>>>>>> Hi Jason/Michael, >>>>>>> >>>>>>> Recently Peter Xu's patch also touched intel-iommu emulation. His >>>>>>> patch shadows second-level page table by capturing iotlb flush >>>>>>> from guest. It would result in page table updating in host. Does >>>>>>> this patch also use the same map/umap API provided by VFIO? >>>>>> Yes, it depends on the iommu notifier too. >>>>>> >>>>>>> If it is, then I think it would also update page table in host. I= t >>>>>>> looks to be a duplicate update. Pls refer to the following >>>>>>> snapshot captured from section 6.5.2.5 of vtd spec. >>>>>>> >>>>>>> "Since translation requests from a device may be serviced by >>>>>>> hardware from the IOTLB, software must always request IOTLB >>>>>>> invalidation >>>>>>> (iotlb_inv_dsc) before requesting corresponding Device-TLB >>>>>>> (dev_tlb_inv_dsc) invalidation." >>>>>>> >>>>>>> Maybe for device-iotlb, we need a separate API which just pass >>>>>>> down the invalidate info without updating page table. Any thought= s? >>>>>> cc Alex. >>>>>> >>>>>> If we want ATS to be visible for guest (but I'm not sure if VFIO >>>>>> support this), we probably need another notifier or a new flag. >>>>> Jason, for assigned device, I think guest could see ATS if the >>>>> assigned device supports ATS. I can see it when passthru iGPU. >>>>> >>>>> Regards, >>>>> Yi L >>>> Good to know this. >>>> >>>> If I understand your suggestion correctly, you want a dedicated API >>>> to flush a hardware device IOTLB. I'm not sure this is really needed= . >>> yes, I'd like to have an extra API besides the current MAP/UNMAP. >> I'm think whether or not we can do this without extra API or even don'= t need to >> care about this. >> >>>> There's some discussion of similar issue in the past (when ATS is >>>> used for virtio- net/vhost), looks like we could solve this by not >>>> trigger the UNMAP notifier unless it was device IOTLB inv desc if AT= S >>>> is enabled for the device? With this remote IOMMU/IOTLB can only get >>>> invalidation request once. For VFIO, the under layer IOMMU can deal >>>> with hardware device IOTLB without any extra efforts. >>> If I catch the background, I think it should be "not trigger the UNMA= P >>> notifier when unless it was device IOTLB inv desc if ATS is enabled f= or the >> device" >> >> Seems not :) >> >> I mean, if ATS is enabled for the device, only trigger UNMAP notifier = when >> processing device IOTLB. Then we can only have flush once. And host IO= MMU >> driver will take care of device IOTLB flush too. > hmmm, how about the iotlb inv desc which is prior to device-iotlb? Any issue in this case? > I'm not sure > if it is practical to ignore the iotlb inv des since there is no SID in= fo in it. Yes, this needs some changes maybe. Thanks > > Regards, > Yi L