From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8olI-0006wY-RK for qemu-devel@nongnu.org; Mon, 21 Nov 2016 08:36:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8olE-0004wF-4i for qemu-devel@nongnu.org; Mon, 21 Nov 2016 08:35:55 -0500 Received: from mail.kernel.org ([198.145.29.136]:53192) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c8olD-0004va-UG for qemu-devel@nongnu.org; Mon, 21 Nov 2016 08:35:52 -0500 Date: Mon, 21 Nov 2016 15:35:44 +0200 From: "Michael S. Tsirkin" Message-ID: <20161121153426-mutt-send-email-mst@kernel.org> References: <1478603064-32562-1-git-send-email-bd.aviv@gmail.com> <1478603064-32562-2-git-send-email-bd.aviv@gmail.com> <20161109235951-mutt-send-email-mst@kernel.org> <41326d6d-7cdd-afba-ca13-8063e077bfbd@redhat.com> <20161111053836-mutt-send-email-mst@kernel.org> <3e4c0566-d450-63a1-6f9e-e215ed77f4f9@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3e4c0566-d450-63a1-6f9e-e215ed77f4f9@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v6 1/3] IOMMU: add option to enable VTD_CAP_CM to vIOMMU capility exposoed to guest List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang Cc: "Aviv B.D" , qemu-devel@nongnu.org, Jan Kiszka , Alex Williamson , Peter Xu On Fri, Nov 11, 2016 at 12:15:48PM +0800, Jason Wang wrote: >=20 >=20 > On 2016=E5=B9=B411=E6=9C=8811=E6=97=A5 11:39, Michael S. Tsirkin wrote: > > On Fri, Nov 11, 2016 at 10:32:42AM +0800, Jason Wang wrote: > > >=20 > > > On 2016=E5=B9=B411=E6=9C=8810=E6=97=A5 06:00, Michael S. Tsirkin wr= ote: > > > > On Wed, Nov 09, 2016 at 03:28:02PM +0800, Jason Wang wrote: > > > > > >=20 > > > > > > On 2016=E5=B9=B411=E6=9C=8808=E6=97=A5 19:04, Aviv B.D wrote: > > > > > > > > From: "Aviv Ben-David" > > > > > > > >=20 > > > > > > > > This capability asks the guest to invalidate cache before= each map operation. > > > > > > > > We can use this invalidation to trap map operations in th= e hypervisor. > > > > > > Hi: > > > > > >=20 > > > > > > Like I've asked twice in the past, I want to know why don't y= ou cache > > > > > > translation faults as what spec required (especially this is = a guest visible > > > > > > behavior)? > > > > > >=20 > > > > > > Btw, please cc me on posting future versions. > > > > > >=20 > > > > > > Thanks > > > > Caching isn't guest visible. > > > Seems not, if one fault mapping were cached by IOTLB. Guest can not= ice this > > > behavior. > > Sorry, I don't get what you are saying. > >=20 > > > > Spec just says you*can* cache, > > > > not that you must. > > > >=20 > > > Yes, but what did in this patch is "don't". What I suggest is just = a "can", > > > since anyway the IOTLB entries were limited and could be replaced b= y other. > > >=20 > > > Thanks > > Have trouble understanding this. Can you given an example of > > a guest visible difference? >=20 > I guess this may do the detection: >=20 > 1) map iova A to be non-present. > 2) invalidate iova A > 3) map iova A to addr B > 4) access iova A >=20 > A correct implemented CM may meet fault in step 4, but with this patch,= we > never. I think that IOTLB is free to invalidate entries at any point, so the fault is not guaranteed on bare metal. --=20 MST