From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:45682)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peterx@redhat.com>) id 1bTqDo-0004g5-PJ
	for qemu-devel@nongnu.org; Sun, 31 Jul 2016 08:52:01 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peterx@redhat.com>) id 1bTqDl-0005W7-MT
	for qemu-devel@nongnu.org; Sun, 31 Jul 2016 08:52:00 -0400
Received: from mx1.redhat.com ([209.132.183.28]:49642)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peterx@redhat.com>) id 1bTqDl-0005W1-HF
	for qemu-devel@nongnu.org; Sun, 31 Jul 2016 08:51:57 -0400
Date: Sun, 31 Jul 2016 20:51:51 +0800
From: Peter Xu <peterx@redhat.com>
Message-ID: <20160731125151.GB6207@pxdev.xzpeter.org>
References: <1469123413-20809-1-git-send-email-mst@redhat.com>
	<1469123413-20809-27-git-send-email-mst@redhat.com>
	<53c0af03-7841-91c2-2eac-55a42b4971db@web.de>
	<20160731035903.GA6207@pxdev.xzpeter.org>
	<49d9598a-9d37-5d57-9b75-753544a6cdaf@web.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <49d9598a-9d37-5d57-9b75-753544a6cdaf@web.de>
Subject: Re: [Qemu-devel] [PULL v5 26/57] x86-iommu: introduce IEC notifiers
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: Jan Kiszka <jan.kiszka@web.de>
Cc: "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>, Richard Henderson <rth@twiddle.net>, Eduardo Habkost <ehabkost@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>

On Sun, Jul 31, 2016 at 02:01:26PM +0200, Jan Kiszka wrote:

[...]

> Yes, there has to be a generic handle for each translation result an
> IOMMU generated. This handle can be stored on the consumer side along
> with the translation request. How a handle is generated should be
> completely up to the IOMMU.
> 
> The consumer should receive a 32-bit (or more) opaque value with each
> translation request (separate parameter) and then again on specific
> invalidation. The latter case may also report a range of handles, to
> make things more efficient (provided the consumer store those handles
> close to each other).

Agreed. So I think masking can still survive to describe "a range of
handles" for AMD IOMMUs, as long as we are sure the masked range
covers the maximum index number of IRTE entry for specific device.

Thanks,

-- peterx