From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55980)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <bd.aviv@gmail.com>) id 1aiHRh-0005XX-Dr
	for qemu-devel@nongnu.org; Tue, 22 Mar 2016 04:13:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <bd.aviv@gmail.com>) id 1aiHRb-0007zf-Gt
	for qemu-devel@nongnu.org; Tue, 22 Mar 2016 04:13:45 -0400
Received: from mail-lb0-x233.google.com ([2a00:1450:4010:c04::233]:32797)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <bd.aviv@gmail.com>) id 1aiHRb-0007zZ-3V
	for qemu-devel@nongnu.org; Tue, 22 Mar 2016 04:13:39 -0400
Received: by mail-lb0-x233.google.com with SMTP id oe12so150739981lbc.0
	for <qemu-devel@nongnu.org>; Tue, 22 Mar 2016 01:13:38 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20160321023012.GA4468@pxdev.xzpeter.org>
References: <CAM3WwMgvSW7c74An0zGk+DbVmPmDpb5Q0ghjLC09H6dXXxaRoQ@mail.gmail.com>
	<56E70871.3050305@gmail.com> <20160315085236.GA23495@pxdev.xzpeter.org>
	<CAM3WwMjACYVF3n_inUVWjzJHAbPvzUjTrvm1q7QNQf+gxxqHMQ@mail.gmail.com>
	<20160318030643.GI23495@pxdev.xzpeter.org>
	<CAM3WwMiW107ETixPdc+SJ=T4xsn-1zBsUfnKt0zbvDzx_iJuaA@mail.gmail.com>
	<20160321023012.GA4468@pxdev.xzpeter.org>
From: "Aviv B.D." <bd.aviv@gmail.com>
Date: Tue, 22 Mar 2016 10:13:18 +0200
Message-ID: <CAM3WwMhJ963UBSKD0Kt4mg1ZZnqDGD03Y_k_ZgKzip7ivDHjAg@mail.gmail.com>
Content-Type: multipart/alternative; boundary=001a1141fcaa55b594052e9eca18
Subject: Re: [Qemu-devel] [PATCH][RFC] IOMMU: Add Support to VFIO devices
 with vIOMMU present
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Xu <peterx@redhat.com>
Cc: marcel@redhat.com, Jan Kiszka <jan.kiszka@siemens.com>, Alex Williamson <alex.williamson@redhat.com>, qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>

--001a1141fcaa55b594052e9eca18
Content-Type: text/plain; charset=UTF-8

On Mon, Mar 21, 2016 at 4:30 AM, Peter Xu <peterx@redhat.com> wrote:

> On Sat, Mar 19, 2016 at 11:40:04AM +0200, Aviv B.D. wrote:
> [...]
> > As far as I understand the code, currently there is no way to turn off
> the
> > IOTLB.
> > Furthermore. the IOTLB is not implemented as LRU, and actually caches
> > (indefinitely)
> > any accessed address, without any size constrains. I use those
> assumptions
> > to know
> > whether the current invalidation is for unmap operation or map operation.
>
> Please have a look at VTD_IOTLB_MAX_SIZE. It seems to be the size of
> the hash.
>
> Btw, I guess it's a much bigger problem if IOTLB has unlimited cache
> size...
>
> Thanks.

-- peterx
>

You are correct, VTD_IOTLB_MAX_SIZE limits the cache size (and reset the
whole cache
if this threshold exceeds...) I will think on another mechanism to identify
the correct
action for each invalidation.

Thanks,
Aviv.

--001a1141fcaa55b594052e9eca18
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Mar 21, 2016 at 4:30 AM, Peter Xu <span dir=3D"ltr">&lt;<a href=
=3D"mailto:peterx@redhat.com" target=3D"_blank">peterx@redhat.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><span class=3D"">On Sat, Mar 19, 2016 at 1=
1:40:04AM +0200, Aviv B.D. wrote:<br>
[...]<br>
</span><span class=3D"">&gt; As far as I understand the code, currently the=
re is no way to turn off the<br>
&gt; IOTLB.<br>
&gt; Furthermore. the IOTLB is not implemented as LRU, and actually caches<=
br>
&gt; (indefinitely)<br>
&gt; any accessed address, without any size constrains. I use those assumpt=
ions<br>
&gt; to know<br>
&gt; whether the current invalidation is for unmap operation or map operati=
on.<br>
<br>
</span>Please have a look at VTD_IOTLB_MAX_SIZE. It seems to be the size of=
<br>
the hash.<br>
<br>
Btw, I guess it&#39;s a much bigger problem if IOTLB has unlimited cache<br=
>
size...<br>
<br>
Thanks.=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">
-- peterx<br></blockquote><div><br></div><div>You are correct, VTD_IOTLB_MA=
X_SIZE limits the cache size (and reset the whole cache=C2=A0</div><div>if =
this threshold exceeds...) I will think on another mechanism to identify th=
e correct=C2=A0</div><div>action for each invalidation.</div><div><br></div=
><div>Thanks,</div><div>Aviv.=C2=A0</div></div><br></div></div>

--001a1141fcaa55b594052e9eca18--