From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756143AbbBCPyb (ORCPT <rfc822;w@1wt.eu>);
	Tue, 3 Feb 2015 10:54:31 -0500
Received: from pandora.arm.linux.org.uk ([78.32.30.218]:45568 "EHLO
	pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754670AbbBCPy2 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 3 Feb 2015 10:54:28 -0500
Date: Tue, 3 Feb 2015 15:54:04 +0000
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linaro-mm-sig@lists.linaro.org,
        Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>,
        Robin Murphy <robin.murphy@arm.com>,
        LKML <linux-kernel@vger.kernel.org>,
        DRI mailing list <dri-devel@lists.freedesktop.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        Rob Clark <robdclark@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
        Tomasz Stanislawski <stanislawski.tomasz@googlemail.com>,
        linux-arm-kernel@lists.infradead.org,
        "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing
 attacher constraints with dma-parms
Message-ID: <20150203155404.GV8656@n2100.arm.linux.org.uk>
References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org>
 <4830208.H6zxrGlT1D@wuerfel>
 <20150203152204.GU8656@n2100.arm.linux.org.uk>
 <3783167.LiVXgA35gN@wuerfel>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3783167.LiVXgA35gN@wuerfel>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Feb 03, 2015 at 04:31:13PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 15:22:05 Russell King - ARM Linux wrote:
> > Don't we already have those in the DMA API?  dma_sync_*() ?
> >
> > dma_map_sg() - sets up the system MMU and deals with initial cache
> > coherency handling.  Device IOMMU being the responsibility of the
> > GPU driver.
> 
> dma_sync_*() works with whatever comes out of dma_map_*(), true,
> but this is not what they want to do here.
>  
> > The GPU can then do dma_sync_*() on the scatterlist as is necessary
> > to synchronise the cache coherency (while respecting the ownership
> > rules - which are very important on ARM to follow as some sync()s are
> > destructive to any dirty data in the CPU cache.)
> > 
> > dma_unmap_sg() tears down the system MMU and deals with the final cache
> > handling.
> > 
> > Why do we need more DMA API interfaces?
> 
> The dma_map_* interfaces assign the virtual addresses internally,
> using typically either a global address space for all devices, or one
> address space per device.

We shouldn't be doing one address space per device for precisely this
reason.  We should be doing one address space per *bus*.  I did have
a nice diagram to illustrate the point in my previous email, but I
deleted it, I wish I hadn't... briefly:

Fig. 1.
                                                 +------------------+
                                                 |+-----+  device   |
CPU--L1cache--L2cache--Memory--SysMMU---<iobus>----IOMMU-->         |
                                                 |+-----+           |
                                                 +------------------+

Fig.1 represents what I'd call the "GPU" issue that we're talking about
in this thread.

Fig. 2.
CPU--L1cache--L2cache--Memory--SysMMU---<iobus>--IOMMU--device

The DMA API should be responsible (at the very least) for everything on
the left of "<iobus>" in and should be providing a dma_addr_t which is
representative of what the device (in Fig.1) as a whole sees.  That's
the "system" part.  

I believe this is the approach which is taken by x86 and similar platforms,
simply because they tend not to have an IOMMU on individual devices (and
if they did, eg, on a PCI card, it's clearly the responsibility of the
device driver.)

Whether the DMA API also handles the IOMMU in Fig.1 or 2 is questionable.
For fig.2, it is entirely possible that the same device could appear
without an IOMMU, and in that scenario, you would want the IOMMU to be
handled transparently.

However, by doing so for everything, you run into exactly the problem
which is being discussed here - the need to separate out the cache
coherency from the IOMMU aspects.  You probably also have a setup very
similar to fig.1 (which is certainly true of Vivante GPUs.)

If you have the need to separately control both, then using the DMA API
to encapsulate both does not make sense - at which point, the DMA API
should be responsible for the minimum only - in other words, everything
to the left of <iobus> (so including the system MMU.)  The control of
the device IOMMU should be the responsibility of device driver in this
case.

So, dma_map_sg() would be responsible for dealing with the CPU cache
coherency issues, and setting up the system MMU.  dma_sync_*() would
be responsible for the CPU cache coherency issues, and dma_unmap_sg()
would (again) deal with the CPU cache and tear down the system MMU
mappings.

Meanwhile, the device driver has ultimate control over its IOMMU, the
creation and destruction of mappings and context switches at the
appropriate times.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52])
	by kanga.kvack.org (Postfix) with ESMTP id B041B6B0038
	for <linux-mm@kvack.org>; Tue,  3 Feb 2015 10:54:32 -0500 (EST)
Received: by mail-wg0-f52.google.com with SMTP id y19so45323987wgg.11
        for <linux-mm@kvack.org>; Tue, 03 Feb 2015 07:54:32 -0800 (PST)
Received: from pandora.arm.linux.org.uk (pandora.arm.linux.org.uk. [2001:4d48:ad52:3201:214:fdff:fe10:1be6])
        by mx.google.com with ESMTPS id x10si31855263wiv.103.2015.02.03.07.54.30
        for <linux-mm@kvack.org>
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Tue, 03 Feb 2015 07:54:31 -0800 (PST)
Date: Tue, 3 Feb 2015 15:54:04 +0000
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
Subject: Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing
 attacher constraints with dma-parms
Message-ID: <20150203155404.GV8656@n2100.arm.linux.org.uk>
References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org>
 <4830208.H6zxrGlT1D@wuerfel>
 <20150203152204.GU8656@n2100.arm.linux.org.uk>
 <3783167.LiVXgA35gN@wuerfel>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3783167.LiVXgA35gN@wuerfel>
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linaro-mm-sig@lists.linaro.org, Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>, Robin Murphy <robin.murphy@arm.com>, LKML <linux-kernel@vger.kernel.org>, DRI mailing list <dri-devel@lists.freedesktop.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, Rob Clark <robdclark@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Tomasz Stanislawski <stanislawski.tomasz@googlemail.com>, linux-arm-kernel@lists.infradead.org, "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>

On Tue, Feb 03, 2015 at 04:31:13PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 15:22:05 Russell King - ARM Linux wrote:
> > Don't we already have those in the DMA API?  dma_sync_*() ?
> >
> > dma_map_sg() - sets up the system MMU and deals with initial cache
> > coherency handling.  Device IOMMU being the responsibility of the
> > GPU driver.
> 
> dma_sync_*() works with whatever comes out of dma_map_*(), true,
> but this is not what they want to do here.
>  
> > The GPU can then do dma_sync_*() on the scatterlist as is necessary
> > to synchronise the cache coherency (while respecting the ownership
> > rules - which are very important on ARM to follow as some sync()s are
> > destructive to any dirty data in the CPU cache.)
> > 
> > dma_unmap_sg() tears down the system MMU and deals with the final cache
> > handling.
> > 
> > Why do we need more DMA API interfaces?
> 
> The dma_map_* interfaces assign the virtual addresses internally,
> using typically either a global address space for all devices, or one
> address space per device.

We shouldn't be doing one address space per device for precisely this
reason.  We should be doing one address space per *bus*.  I did have
a nice diagram to illustrate the point in my previous email, but I
deleted it, I wish I hadn't... briefly:

Fig. 1.
                                                 +------------------+
                                                 |+-----+  device   |
CPU--L1cache--L2cache--Memory--SysMMU---<iobus>----IOMMU-->         |
                                                 |+-----+           |
                                                 +------------------+

Fig.1 represents what I'd call the "GPU" issue that we're talking about
in this thread.

Fig. 2.
CPU--L1cache--L2cache--Memory--SysMMU---<iobus>--IOMMU--device

The DMA API should be responsible (at the very least) for everything on
the left of "<iobus>" in and should be providing a dma_addr_t which is
representative of what the device (in Fig.1) as a whole sees.  That's
the "system" part.  

I believe this is the approach which is taken by x86 and similar platforms,
simply because they tend not to have an IOMMU on individual devices (and
if they did, eg, on a PCI card, it's clearly the responsibility of the
device driver.)

Whether the DMA API also handles the IOMMU in Fig.1 or 2 is questionable.
For fig.2, it is entirely possible that the same device could appear
without an IOMMU, and in that scenario, you would want the IOMMU to be
handled transparently.

However, by doing so for everything, you run into exactly the problem
which is being discussed here - the need to separate out the cache
coherency from the IOMMU aspects.  You probably also have a setup very
similar to fig.1 (which is certainly true of Vivante GPUs.)

If you have the need to separately control both, then using the DMA API
to encapsulate both does not make sense - at which point, the DMA API
should be responsible for the minimum only - in other words, everything
to the left of <iobus> (so including the system MMU.)  The control of
the device IOMMU should be the responsibility of device driver in this
case.

So, dma_map_sg() would be responsible for dealing with the CPU cache
coherency issues, and setting up the system MMU.  dma_sync_*() would
be responsible for the CPU cache coherency issues, and dma_unmap_sg()
would (again) deal with the CPU cache and tear down the system MMU
mappings.

Meanwhile, the device driver has ultimate control over its IOMMU, the
creation and destruction of mappings and context switches at the
appropriate times.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

From mboxrd@z Thu Jan  1 00:00:00 1970
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 3 Feb 2015 15:54:04 +0000
Subject: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing
 attacher constraints with dma-parms
In-Reply-To: <3783167.LiVXgA35gN@wuerfel>
References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org>
 <4830208.H6zxrGlT1D@wuerfel>
 <20150203152204.GU8656@n2100.arm.linux.org.uk>
 <3783167.LiVXgA35gN@wuerfel>
Message-ID: <20150203155404.GV8656@n2100.arm.linux.org.uk>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Tue, Feb 03, 2015 at 04:31:13PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 15:22:05 Russell King - ARM Linux wrote:
> > Don't we already have those in the DMA API?  dma_sync_*() ?
> >
> > dma_map_sg() - sets up the system MMU and deals with initial cache
> > coherency handling.  Device IOMMU being the responsibility of the
> > GPU driver.
> 
> dma_sync_*() works with whatever comes out of dma_map_*(), true,
> but this is not what they want to do here.
>  
> > The GPU can then do dma_sync_*() on the scatterlist as is necessary
> > to synchronise the cache coherency (while respecting the ownership
> > rules - which are very important on ARM to follow as some sync()s are
> > destructive to any dirty data in the CPU cache.)
> > 
> > dma_unmap_sg() tears down the system MMU and deals with the final cache
> > handling.
> > 
> > Why do we need more DMA API interfaces?
> 
> The dma_map_* interfaces assign the virtual addresses internally,
> using typically either a global address space for all devices, or one
> address space per device.

We shouldn't be doing one address space per device for precisely this
reason.  We should be doing one address space per *bus*.  I did have
a nice diagram to illustrate the point in my previous email, but I
deleted it, I wish I hadn't... briefly:

Fig. 1.
                                                 +------------------+
                                                 |+-----+  device   |
CPU--L1cache--L2cache--Memory--SysMMU---<iobus>----IOMMU-->         |
                                                 |+-----+           |
                                                 +------------------+

Fig.1 represents what I'd call the "GPU" issue that we're talking about
in this thread.

Fig. 2.
CPU--L1cache--L2cache--Memory--SysMMU---<iobus>--IOMMU--device

The DMA API should be responsible (at the very least) for everything on
the left of "<iobus>" in and should be providing a dma_addr_t which is
representative of what the device (in Fig.1) as a whole sees.  That's
the "system" part.  

I believe this is the approach which is taken by x86 and similar platforms,
simply because they tend not to have an IOMMU on individual devices (and
if they did, eg, on a PCI card, it's clearly the responsibility of the
device driver.)

Whether the DMA API also handles the IOMMU in Fig.1 or 2 is questionable.
For fig.2, it is entirely possible that the same device could appear
without an IOMMU, and in that scenario, you would want the IOMMU to be
handled transparently.

However, by doing so for everything, you run into exactly the problem
which is being discussed here - the need to separate out the cache
coherency from the IOMMU aspects.  You probably also have a setup very
similar to fig.1 (which is certainly true of Vivante GPUs.)

If you have the need to separately control both, then using the DMA API
to encapsulate both does not make sense - at which point, the DMA API
should be responsible for the minimum only - in other words, everything
to the left of <iobus> (so including the system MMU.)  The control of
the device IOMMU should be the responsibility of device driver in this
case.

So, dma_map_sg() would be responsible for dealing with the CPU cache
coherency issues, and setting up the system MMU.  dma_sync_*() would
be responsible for the CPU cache coherency issues, and dma_unmap_sg()
would (again) deal with the CPU cache and tear down the system MMU
mappings.

Meanwhile, the device driver has ultimate control over its IOMMU, the
creation and destruction of mappings and context switches at the
appropriate times.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
Subject: Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing
 attacher constraints with dma-parms
Date: Tue, 3 Feb 2015 15:54:04 +0000
Message-ID: <20150203155404.GV8656@n2100.arm.linux.org.uk>
References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org>
 <4830208.H6zxrGlT1D@wuerfel>
 <20150203152204.GU8656@n2100.arm.linux.org.uk>
 <3783167.LiVXgA35gN@wuerfel>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Return-path: <dri-devel-bounces@lists.freedesktop.org>
Received: from pandora.arm.linux.org.uk (pandora.arm.linux.org.uk
 [78.32.30.218])
 by gabe.freedesktop.org (Postfix) with ESMTP id 1399A6E084
 for <dri-devel@lists.freedesktop.org>; Tue,  3 Feb 2015 07:54:29 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <3783167.LiVXgA35gN@wuerfel>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/dri-devel>,
 <mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dri-devel>,
 <mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel" <dri-devel-bounces@lists.freedesktop.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>, Tomasz Stanislawski <stanislawski.tomasz@googlemail.com>, LKML <linux-kernel@vger.kernel.org>, DRI mailing list <dri-devel@lists.freedesktop.org>, linaro-mm-sig@lists.linaro.org, "linux-mm@kvack.org" <linux-mm@kvack.org>, Robin Murphy <robin.murphy@arm.com>, linux-arm-kernel@lists.infradead.org, "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
List-Id: dri-devel@lists.freedesktop.org

T24gVHVlLCBGZWIgMDMsIDIwMTUgYXQgMDQ6MzE6MTNQTSArMDEwMCwgQXJuZCBCZXJnbWFubiB3
cm90ZToKPiBPbiBUdWVzZGF5IDAzIEZlYnJ1YXJ5IDIwMTUgMTU6MjI6MDUgUnVzc2VsbCBLaW5n
IC0gQVJNIExpbnV4IHdyb3RlOgo+ID4gRG9uJ3Qgd2UgYWxyZWFkeSBoYXZlIHRob3NlIGluIHRo
ZSBETUEgQVBJPyAgZG1hX3N5bmNfKigpID8KPiA+Cj4gPiBkbWFfbWFwX3NnKCkgLSBzZXRzIHVw
IHRoZSBzeXN0ZW0gTU1VIGFuZCBkZWFscyB3aXRoIGluaXRpYWwgY2FjaGUKPiA+IGNvaGVyZW5j
eSBoYW5kbGluZy4gIERldmljZSBJT01NVSBiZWluZyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhl
Cj4gPiBHUFUgZHJpdmVyLgo+IAo+IGRtYV9zeW5jXyooKSB3b3JrcyB3aXRoIHdoYXRldmVyIGNv
bWVzIG91dCBvZiBkbWFfbWFwXyooKSwgdHJ1ZSwKPiBidXQgdGhpcyBpcyBub3Qgd2hhdCB0aGV5
IHdhbnQgdG8gZG8gaGVyZS4KPiAgCj4gPiBUaGUgR1BVIGNhbiB0aGVuIGRvIGRtYV9zeW5jXyoo
KSBvbiB0aGUgc2NhdHRlcmxpc3QgYXMgaXMgbmVjZXNzYXJ5Cj4gPiB0byBzeW5jaHJvbmlzZSB0
aGUgY2FjaGUgY29oZXJlbmN5ICh3aGlsZSByZXNwZWN0aW5nIHRoZSBvd25lcnNoaXAKPiA+IHJ1
bGVzIC0gd2hpY2ggYXJlIHZlcnkgaW1wb3J0YW50IG9uIEFSTSB0byBmb2xsb3cgYXMgc29tZSBz
eW5jKClzIGFyZQo+ID4gZGVzdHJ1Y3RpdmUgdG8gYW55IGRpcnR5IGRhdGEgaW4gdGhlIENQVSBj
YWNoZS4pCj4gPiAKPiA+IGRtYV91bm1hcF9zZygpIHRlYXJzIGRvd24gdGhlIHN5c3RlbSBNTVUg
YW5kIGRlYWxzIHdpdGggdGhlIGZpbmFsIGNhY2hlCj4gPiBoYW5kbGluZy4KPiA+IAo+ID4gV2h5
IGRvIHdlIG5lZWQgbW9yZSBETUEgQVBJIGludGVyZmFjZXM/Cj4gCj4gVGhlIGRtYV9tYXBfKiBp
bnRlcmZhY2VzIGFzc2lnbiB0aGUgdmlydHVhbCBhZGRyZXNzZXMgaW50ZXJuYWxseSwKPiB1c2lu
ZyB0eXBpY2FsbHkgZWl0aGVyIGEgZ2xvYmFsIGFkZHJlc3Mgc3BhY2UgZm9yIGFsbCBkZXZpY2Vz
LCBvciBvbmUKPiBhZGRyZXNzIHNwYWNlIHBlciBkZXZpY2UuCgpXZSBzaG91bGRuJ3QgYmUgZG9p
bmcgb25lIGFkZHJlc3Mgc3BhY2UgcGVyIGRldmljZSBmb3IgcHJlY2lzZWx5IHRoaXMKcmVhc29u
LiAgV2Ugc2hvdWxkIGJlIGRvaW5nIG9uZSBhZGRyZXNzIHNwYWNlIHBlciAqYnVzKi4gIEkgZGlk
IGhhdmUKYSBuaWNlIGRpYWdyYW0gdG8gaWxsdXN0cmF0ZSB0aGUgcG9pbnQgaW4gbXkgcHJldmlv
dXMgZW1haWwsIGJ1dCBJCmRlbGV0ZWQgaXQsIEkgd2lzaCBJIGhhZG4ndC4uLiBicmllZmx5OgoK
RmlnLiAxLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Ky0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwrLS0tLS0rICBkZXZpY2UgICB8CkNQVS0tTDFjYWNoZS0tTDJjYWNoZS0t
TWVtb3J5LS1TeXNNTVUtLS08aW9idXM+LS0tLUlPTU1VLS0+ICAgICAgICAgfAogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCstLS0tLSsgICAgICAgICAg
IHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0t
LS0tLS0tLS0tLS0tLS0rCgpGaWcuMSByZXByZXNlbnRzIHdoYXQgSSdkIGNhbGwgdGhlICJHUFUi
IGlzc3VlIHRoYXQgd2UncmUgdGFsa2luZyBhYm91dAppbiB0aGlzIHRocmVhZC4KCkZpZy4gMi4K
Q1BVLS1MMWNhY2hlLS1MMmNhY2hlLS1NZW1vcnktLVN5c01NVS0tLTxpb2J1cz4tLUlPTU1VLS1k
ZXZpY2UKClRoZSBETUEgQVBJIHNob3VsZCBiZSByZXNwb25zaWJsZSAoYXQgdGhlIHZlcnkgbGVh
c3QpIGZvciBldmVyeXRoaW5nIG9uCnRoZSBsZWZ0IG9mICI8aW9idXM+IiBpbiBhbmQgc2hvdWxk
IGJlIHByb3ZpZGluZyBhIGRtYV9hZGRyX3Qgd2hpY2ggaXMKcmVwcmVzZW50YXRpdmUgb2Ygd2hh
dCB0aGUgZGV2aWNlIChpbiBGaWcuMSkgYXMgYSB3aG9sZSBzZWVzLiAgVGhhdCdzCnRoZSAic3lz
dGVtIiBwYXJ0LiAgCgpJIGJlbGlldmUgdGhpcyBpcyB0aGUgYXBwcm9hY2ggd2hpY2ggaXMgdGFr
ZW4gYnkgeDg2IGFuZCBzaW1pbGFyIHBsYXRmb3JtcywKc2ltcGx5IGJlY2F1c2UgdGhleSB0ZW5k
IG5vdCB0byBoYXZlIGFuIElPTU1VIG9uIGluZGl2aWR1YWwgZGV2aWNlcyAoYW5kCmlmIHRoZXkg
ZGlkLCBlZywgb24gYSBQQ0kgY2FyZCwgaXQncyBjbGVhcmx5IHRoZSByZXNwb25zaWJpbGl0eSBv
ZiB0aGUKZGV2aWNlIGRyaXZlci4pCgpXaGV0aGVyIHRoZSBETUEgQVBJIGFsc28gaGFuZGxlcyB0
aGUgSU9NTVUgaW4gRmlnLjEgb3IgMiBpcyBxdWVzdGlvbmFibGUuCkZvciBmaWcuMiwgaXQgaXMg
ZW50aXJlbHkgcG9zc2libGUgdGhhdCB0aGUgc2FtZSBkZXZpY2UgY291bGQgYXBwZWFyCndpdGhv
dXQgYW4gSU9NTVUsIGFuZCBpbiB0aGF0IHNjZW5hcmlvLCB5b3Ugd291bGQgd2FudCB0aGUgSU9N
TVUgdG8gYmUKaGFuZGxlZCB0cmFuc3BhcmVudGx5LgoKSG93ZXZlciwgYnkgZG9pbmcgc28gZm9y
IGV2ZXJ5dGhpbmcsIHlvdSBydW4gaW50byBleGFjdGx5IHRoZSBwcm9ibGVtCndoaWNoIGlzIGJl
aW5nIGRpc2N1c3NlZCBoZXJlIC0gdGhlIG5lZWQgdG8gc2VwYXJhdGUgb3V0IHRoZSBjYWNoZQpj
b2hlcmVuY3kgZnJvbSB0aGUgSU9NTVUgYXNwZWN0cy4gIFlvdSBwcm9iYWJseSBhbHNvIGhhdmUg
YSBzZXR1cCB2ZXJ5CnNpbWlsYXIgdG8gZmlnLjEgKHdoaWNoIGlzIGNlcnRhaW5seSB0cnVlIG9m
IFZpdmFudGUgR1BVcy4pCgpJZiB5b3UgaGF2ZSB0aGUgbmVlZCB0byBzZXBhcmF0ZWx5IGNvbnRy
b2wgYm90aCwgdGhlbiB1c2luZyB0aGUgRE1BIEFQSQp0byBlbmNhcHN1bGF0ZSBib3RoIGRvZXMg
bm90IG1ha2Ugc2Vuc2UgLSBhdCB3aGljaCBwb2ludCwgdGhlIERNQSBBUEkKc2hvdWxkIGJlIHJl
c3BvbnNpYmxlIGZvciB0aGUgbWluaW11bSBvbmx5IC0gaW4gb3RoZXIgd29yZHMsIGV2ZXJ5dGhp
bmcKdG8gdGhlIGxlZnQgb2YgPGlvYnVzPiAoc28gaW5jbHVkaW5nIHRoZSBzeXN0ZW0gTU1VLikg
IFRoZSBjb250cm9sIG9mCnRoZSBkZXZpY2UgSU9NTVUgc2hvdWxkIGJlIHRoZSByZXNwb25zaWJp
bGl0eSBvZiBkZXZpY2UgZHJpdmVyIGluIHRoaXMKY2FzZS4KClNvLCBkbWFfbWFwX3NnKCkgd291
bGQgYmUgcmVzcG9uc2libGUgZm9yIGRlYWxpbmcgd2l0aCB0aGUgQ1BVIGNhY2hlCmNvaGVyZW5j
eSBpc3N1ZXMsIGFuZCBzZXR0aW5nIHVwIHRoZSBzeXN0ZW0gTU1VLiAgZG1hX3N5bmNfKigpIHdv
dWxkCmJlIHJlc3BvbnNpYmxlIGZvciB0aGUgQ1BVIGNhY2hlIGNvaGVyZW5jeSBpc3N1ZXMsIGFu
ZCBkbWFfdW5tYXBfc2coKQp3b3VsZCAoYWdhaW4pIGRlYWwgd2l0aCB0aGUgQ1BVIGNhY2hlIGFu
ZCB0ZWFyIGRvd24gdGhlIHN5c3RlbSBNTVUKbWFwcGluZ3MuCgpNZWFud2hpbGUsIHRoZSBkZXZp
Y2UgZHJpdmVyIGhhcyB1bHRpbWF0ZSBjb250cm9sIG92ZXIgaXRzIElPTU1VLCB0aGUKY3JlYXRp
b24gYW5kIGRlc3RydWN0aW9uIG9mIG1hcHBpbmdzIGFuZCBjb250ZXh0IHN3aXRjaGVzIGF0IHRo
ZQphcHByb3ByaWF0ZSB0aW1lcy4KCi0tIApGVFRDIGJyb2FkYmFuZCBmb3IgMC44bWlsZSBsaW5l
OiBjdXJyZW50bHkgYXQgMTAuNU1icHMgZG93biA0MDBrYnBzIHVwCmFjY29yZGluZyB0byBzcGVl
ZHRlc3QubmV0LgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcK
aHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo=