diff for duplicates of <20180907142504.5034351e@jacob-builder>

diff --git a/a/1.txt b/N1/1.txt
index 897ab0e..e8f5097 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,151 +1,114 @@
-On Fri, 7 Sep 2018 20:02:54 +0200
-Christian König <christian.koenig@amd.com> wrote:
-
-> Am 07.09.2018 um 17:45 schrieb Jean-Philippe Brucker:
-> > On 07/09/2018 09:55, Christian König wrote:  
-> >> I will take this as an opportunity to summarize some of the
-> >> requirements we have for PASID management from the amdgpu driver
-> >> point of view:  
-> > That's incredibly useful, thanks :)
-> >  
-> >> 1. We need to be able to allocate PASID between 1 and some
-> >> maximum. Zero is reserved as far as I know, but we don't necessary
-> >> need a minimum.  
->  [...]  
-> >> 2. We need to be able to allocate PASIDs without a process address
-> >> space backing it. E.g. our hardware uses PASIDs even without
-> >> Shared Virtual Addressing enabled to distinct clients from each
-> >> other. Would be a pity if we need to still have a separate PASID
-> >> handling because the system wide is only available when IOMMU is
-> >> turned on.  
->  [...]  
-> 
-> I agree on that.
-> 
-> > iommu-sva expects everywhere that the device has an iommu_domain,
-> > it's the first thing we check on entry. Bypassing all of this would
-> > call idr_alloc() directly, and wouldn't have any code in common
-> > with the current iommu-sva. So it seems like you need a layer on
-> > top of iommu-sva calling idr_alloc() when an IOMMU isn't present,
-> > but I don't think it should be in drivers/iommu/  
-> 
-> In this case I question if the PASID handling should be under 
-> drivers/iommu at all.
-> 
-> See I can have a mix of VM context which are bound to processes (some 
-> few) and VM contexts which are standalone and doesn't care for a
-> process address space. But for each VM context I need a distinct
-> PASID for the hardware to work.
-> 
-> I can live if we say if IOMMU is completely disabled we use a simple
-> ida to allocate them, but when IOMMU is enabled I certainly need a
-> way to reserve a PASID without an associated process.
-> 
-VT-d would also have such requirement. There is a virtual command
-register for allocate and free PASID for VM use. When that PASID
-allocation request gets propagated to the host IOMMU driver, we need to
-allocate PASID w/o mm.
-
-If the PASID allocation is done via VFIO, can we have FD to track PASID
-life cycle instead of mm_exit()? i.e. all FDs get closed before
-mm_exit, I assume?
-
-> >> 3. Even after destruction of a process address space we need some
-> >> grace period before a PASID is reused because it can be that the
-> >> specific PASID is still in some hardware queues etc...
-> >>           At bare minimum all device drivers using process binding
-> >> need to explicitly note to the core when they are done with a
-> >> PASID.  
-> > Right, much of the horribleness in iommu-sva deals with this:
-> >
-> > The process dies, iommu-sva is notified and calls the mm_exit()
-> > function passed by the device driver to iommu_sva_device_init(). In
-> > mm_exit() the device driver needs to clear any reference to the
-> > PASID in hardware and in its own structures. When the device driver
-> > returns from mm_exit(), it effectively tells the core that it has
-> > finished using the PASID, and iommu-sva can reuse the PASID for
-> > another process. mm_exit() is allowed to block, so the device
-> > driver has time to clean up and flush the queues.
-> >
-> > If the device driver finishes using the PASID before the process
-> > exits, it just calls unbind().  
-> 
-> Exactly that's what Michal Hocko is probably going to not like at all.
-> 
-> Can we have a different approach where each driver is informed by the 
-> mm_exit(), but needs to explicitly call unbind() before a PASID is
-> reused?
-> 
-> During that teardown transition it would be ideal if that PASID only 
-> points to a dummy root page directory with only invalid entries.
-> 
-I guess this can be vendor specific, In VT-d I plan to mark PASID
-entry not present and disable fault reporting while draining remaining
-activities.
-
-> >  
-> >> 4. It would be nice to have to be able to set a "void *" for each
-> >> PASID/device combination while binding to a process which then can
-> >> be queried later on based on the PASID.
-> >>           E.g. when you have a per PASID/device structure around
-> >> anyway, just add an extra field.  
-> > iommu_sva_bind_device() takes a "drvdata" pointer that is stored
-> > internally for the PASID/device combination (iommu_bond). It is
-> > passed to mm_exit(), but I haven't added anything for the device
-> > driver to query it back.  
-> 
-> Nice! Looks like all we need additionally is a function to retrieve
-> that based on the PASID.
-> 
-> >> 5. It would be nice to have to allocate multiple PASIDs for the
-> >> same process address space.
-> >>           E.g. some teams at AMD want to use a separate GPU
-> >> address space for their userspace client library. I'm still trying
-> >> to avoid that, but it is perfectly possible that we are going to
-> >> need that.  
-> > Two PASIDs pointing to the same process pgd? At first glance it
-> > seems feasible, maybe with a flag passed to bind() and a few
-> > changes to internal structures. It will duplicate ATC invalidation
-> > commands for each process address space change (munmap etc) so you
-> > might take a performance hit.
-> >
-> > Intel's SVM code has the SVM_FLAG_PRIVATE_PASID which seems similar
-> > to what you describe, but I don't plan to support it in this series
-> > (the io_mm model is already pretty complicated). I think it can be
-> > added without too much effort in a future series, though with a
-> > different flag name since we'd like to use "private PASID" for
-> > something else
-> > (https://www.spinics.net/lists/dri-devel/msg177007.html).  
-> 
-> To be honest I hoped that you would say: No never! So that I have a
-> good argument to pushback on such requirements :)
-> 
-> But if it's doable it would be at least nice to have for debugging.
-> 
-> Thanks a lot for working on that,
-> Christian.
-> 
-> >
-> > Thanks,
-> > Jean
-> >  
-> >>           Additional to that it is sometimes quite useful for
-> >> debugging to isolate where exactly an incorrect access (segfault)
-> >> is coming from.
-> >>
-> >> Let me know if there are some problems with that, especially I
-> >> want to know if there is pushback on #5 so that I can forward
-> >> that :)
-> >>
-> >> Thanks,
-> >> Christian.
-> >>  
-> >>> Thanks,
-> >>> Jean  
-> 
-
-[Jacob Pan]
-_______________________________________________
-iommu mailing list
-iommu@lists.linux-foundation.org
-https://lists.linuxfoundation.org/mailman/listinfo/iommu
+T24gRnJpLCA3IFNlcCAyMDE4IDIwOjAyOjU0ICswMjAwCkNocmlzdGlhbiBLw7ZuaWcgPGNocmlz
+dGlhbi5rb2VuaWdAYW1kLmNvbT4gd3JvdGU6Cgo+IEFtIDA3LjA5LjIwMTggdW0gMTc6NDUgc2No
+cmllYiBKZWFuLVBoaWxpcHBlIEJydWNrZXI6Cj4gPiBPbiAwNy8wOS8yMDE4IDA5OjU1LCBDaHJp
+c3RpYW4gS8O2bmlnIHdyb3RlOiAgCj4gPj4gSSB3aWxsIHRha2UgdGhpcyBhcyBhbiBvcHBvcnR1
+bml0eSB0byBzdW1tYXJpemUgc29tZSBvZiB0aGUKPiA+PiByZXF1aXJlbWVudHMgd2UgaGF2ZSBm
+b3IgUEFTSUQgbWFuYWdlbWVudCBmcm9tIHRoZSBhbWRncHUgZHJpdmVyCj4gPj4gcG9pbnQgb2Yg
+dmlldzogIAo+ID4gVGhhdCdzIGluY3JlZGlibHkgdXNlZnVsLCB0aGFua3MgOikKPiA+ICAKPiA+
+PiAxLiBXZSBuZWVkIHRvIGJlIGFibGUgdG8gYWxsb2NhdGUgUEFTSUQgYmV0d2VlbiAxIGFuZCBz
+b21lCj4gPj4gbWF4aW11bS4gWmVybyBpcyByZXNlcnZlZCBhcyBmYXIgYXMgSSBrbm93LCBidXQg
+d2UgZG9uJ3QgbmVjZXNzYXJ5Cj4gPj4gbmVlZCBhIG1pbmltdW0uICAKPiAgWy4uLl0gIAo+ID4+
+IDIuIFdlIG5lZWQgdG8gYmUgYWJsZSB0byBhbGxvY2F0ZSBQQVNJRHMgd2l0aG91dCBhIHByb2Nl
+c3MgYWRkcmVzcwo+ID4+IHNwYWNlIGJhY2tpbmcgaXQuIEUuZy4gb3VyIGhhcmR3YXJlIHVzZXMg
+UEFTSURzIGV2ZW4gd2l0aG91dAo+ID4+IFNoYXJlZCBWaXJ0dWFsIEFkZHJlc3NpbmcgZW5hYmxl
+ZCB0byBkaXN0aW5jdCBjbGllbnRzIGZyb20gZWFjaAo+ID4+IG90aGVyLiBXb3VsZCBiZSBhIHBp
+dHkgaWYgd2UgbmVlZCB0byBzdGlsbCBoYXZlIGEgc2VwYXJhdGUgUEFTSUQKPiA+PiBoYW5kbGlu
+ZyBiZWNhdXNlIHRoZSBzeXN0ZW0gd2lkZSBpcyBvbmx5IGF2YWlsYWJsZSB3aGVuIElPTU1VIGlz
+Cj4gPj4gdHVybmVkIG9uLiAgCj4gIFsuLi5dICAKPiAKPiBJIGFncmVlIG9uIHRoYXQuCj4gCj4g
+PiBpb21tdS1zdmEgZXhwZWN0cyBldmVyeXdoZXJlIHRoYXQgdGhlIGRldmljZSBoYXMgYW4gaW9t
+bXVfZG9tYWluLAo+ID4gaXQncyB0aGUgZmlyc3QgdGhpbmcgd2UgY2hlY2sgb24gZW50cnkuIEJ5
+cGFzc2luZyBhbGwgb2YgdGhpcyB3b3VsZAo+ID4gY2FsbCBpZHJfYWxsb2MoKSBkaXJlY3RseSwg
+YW5kIHdvdWxkbid0IGhhdmUgYW55IGNvZGUgaW4gY29tbW9uCj4gPiB3aXRoIHRoZSBjdXJyZW50
+IGlvbW11LXN2YS4gU28gaXQgc2VlbXMgbGlrZSB5b3UgbmVlZCBhIGxheWVyIG9uCj4gPiB0b3Ag
+b2YgaW9tbXUtc3ZhIGNhbGxpbmcgaWRyX2FsbG9jKCkgd2hlbiBhbiBJT01NVSBpc24ndCBwcmVz
+ZW50LAo+ID4gYnV0IEkgZG9uJ3QgdGhpbmsgaXQgc2hvdWxkIGJlIGluIGRyaXZlcnMvaW9tbXUv
+ICAKPiAKPiBJbiB0aGlzIGNhc2UgSSBxdWVzdGlvbiBpZiB0aGUgUEFTSUQgaGFuZGxpbmcgc2hv
+dWxkIGJlIHVuZGVyIAo+IGRyaXZlcnMvaW9tbXUgYXQgYWxsLgo+IAo+IFNlZSBJIGNhbiBoYXZl
+IGEgbWl4IG9mIFZNIGNvbnRleHQgd2hpY2ggYXJlIGJvdW5kIHRvIHByb2Nlc3NlcyAoc29tZSAK
+PiBmZXcpIGFuZCBWTSBjb250ZXh0cyB3aGljaCBhcmUgc3RhbmRhbG9uZSBhbmQgZG9lc24ndCBj
+YXJlIGZvciBhCj4gcHJvY2VzcyBhZGRyZXNzIHNwYWNlLiBCdXQgZm9yIGVhY2ggVk0gY29udGV4
+dCBJIG5lZWQgYSBkaXN0aW5jdAo+IFBBU0lEIGZvciB0aGUgaGFyZHdhcmUgdG8gd29yay4KPiAK
+PiBJIGNhbiBsaXZlIGlmIHdlIHNheSBpZiBJT01NVSBpcyBjb21wbGV0ZWx5IGRpc2FibGVkIHdl
+IHVzZSBhIHNpbXBsZQo+IGlkYSB0byBhbGxvY2F0ZSB0aGVtLCBidXQgd2hlbiBJT01NVSBpcyBl
+bmFibGVkIEkgY2VydGFpbmx5IG5lZWQgYQo+IHdheSB0byByZXNlcnZlIGEgUEFTSUQgd2l0aG91
+dCBhbiBhc3NvY2lhdGVkIHByb2Nlc3MuCj4gClZULWQgd291bGQgYWxzbyBoYXZlIHN1Y2ggcmVx
+dWlyZW1lbnQuIFRoZXJlIGlzIGEgdmlydHVhbCBjb21tYW5kCnJlZ2lzdGVyIGZvciBhbGxvY2F0
+ZSBhbmQgZnJlZSBQQVNJRCBmb3IgVk0gdXNlLiBXaGVuIHRoYXQgUEFTSUQKYWxsb2NhdGlvbiBy
+ZXF1ZXN0IGdldHMgcHJvcGFnYXRlZCB0byB0aGUgaG9zdCBJT01NVSBkcml2ZXIsIHdlIG5lZWQg
+dG8KYWxsb2NhdGUgUEFTSUQgdy9vIG1tLgoKSWYgdGhlIFBBU0lEIGFsbG9jYXRpb24gaXMgZG9u
+ZSB2aWEgVkZJTywgY2FuIHdlIGhhdmUgRkQgdG8gdHJhY2sgUEFTSUQKbGlmZSBjeWNsZSBpbnN0
+ZWFkIG9mIG1tX2V4aXQoKT8gaS5lLiBhbGwgRkRzIGdldCBjbG9zZWQgYmVmb3JlCm1tX2V4aXQs
+IEkgYXNzdW1lPwoKPiA+PiAzLiBFdmVuIGFmdGVyIGRlc3RydWN0aW9uIG9mIGEgcHJvY2VzcyBh
+ZGRyZXNzIHNwYWNlIHdlIG5lZWQgc29tZQo+ID4+IGdyYWNlIHBlcmlvZCBiZWZvcmUgYSBQQVNJ
+RCBpcyByZXVzZWQgYmVjYXVzZSBpdCBjYW4gYmUgdGhhdCB0aGUKPiA+PiBzcGVjaWZpYyBQQVNJ
+RCBpcyBzdGlsbCBpbiBzb21lIGhhcmR3YXJlIHF1ZXVlcyBldGMuLi4KPiA+PiAgIMKgwqDCoCDC
+oMKgwqAgQXQgYmFyZSBtaW5pbXVtIGFsbCBkZXZpY2UgZHJpdmVycyB1c2luZyBwcm9jZXNzIGJp
+bmRpbmcKPiA+PiBuZWVkIHRvIGV4cGxpY2l0bHkgbm90ZSB0byB0aGUgY29yZSB3aGVuIHRoZXkg
+YXJlIGRvbmUgd2l0aCBhCj4gPj4gUEFTSUQuICAKPiA+IFJpZ2h0LCBtdWNoIG9mIHRoZSBob3Jy
+aWJsZW5lc3MgaW4gaW9tbXUtc3ZhIGRlYWxzIHdpdGggdGhpczoKPiA+Cj4gPiBUaGUgcHJvY2Vz
+cyBkaWVzLCBpb21tdS1zdmEgaXMgbm90aWZpZWQgYW5kIGNhbGxzIHRoZSBtbV9leGl0KCkKPiA+
+IGZ1bmN0aW9uIHBhc3NlZCBieSB0aGUgZGV2aWNlIGRyaXZlciB0byBpb21tdV9zdmFfZGV2aWNl
+X2luaXQoKS4gSW4KPiA+IG1tX2V4aXQoKSB0aGUgZGV2aWNlIGRyaXZlciBuZWVkcyB0byBjbGVh
+ciBhbnkgcmVmZXJlbmNlIHRvIHRoZQo+ID4gUEFTSUQgaW4gaGFyZHdhcmUgYW5kIGluIGl0cyBv
+d24gc3RydWN0dXJlcy4gV2hlbiB0aGUgZGV2aWNlIGRyaXZlcgo+ID4gcmV0dXJucyBmcm9tIG1t
+X2V4aXQoKSwgaXQgZWZmZWN0aXZlbHkgdGVsbHMgdGhlIGNvcmUgdGhhdCBpdCBoYXMKPiA+IGZp
+bmlzaGVkIHVzaW5nIHRoZSBQQVNJRCwgYW5kIGlvbW11LXN2YSBjYW4gcmV1c2UgdGhlIFBBU0lE
+IGZvcgo+ID4gYW5vdGhlciBwcm9jZXNzLiBtbV9leGl0KCkgaXMgYWxsb3dlZCB0byBibG9jaywg
+c28gdGhlIGRldmljZQo+ID4gZHJpdmVyIGhhcyB0aW1lIHRvIGNsZWFuIHVwIGFuZCBmbHVzaCB0
+aGUgcXVldWVzLgo+ID4KPiA+IElmIHRoZSBkZXZpY2UgZHJpdmVyIGZpbmlzaGVzIHVzaW5nIHRo
+ZSBQQVNJRCBiZWZvcmUgdGhlIHByb2Nlc3MKPiA+IGV4aXRzLCBpdCBqdXN0IGNhbGxzIHVuYmlu
+ZCgpLiAgCj4gCj4gRXhhY3RseSB0aGF0J3Mgd2hhdCBNaWNoYWwgSG9ja28gaXMgcHJvYmFibHkg
+Z29pbmcgdG8gbm90IGxpa2UgYXQgYWxsLgo+IAo+IENhbiB3ZSBoYXZlIGEgZGlmZmVyZW50IGFw
+cHJvYWNoIHdoZXJlIGVhY2ggZHJpdmVyIGlzIGluZm9ybWVkIGJ5IHRoZSAKPiBtbV9leGl0KCks
+IGJ1dCBuZWVkcyB0byBleHBsaWNpdGx5IGNhbGwgdW5iaW5kKCkgYmVmb3JlIGEgUEFTSUQgaXMK
+PiByZXVzZWQ/Cj4gCj4gRHVyaW5nIHRoYXQgdGVhcmRvd24gdHJhbnNpdGlvbiBpdCB3b3VsZCBi
+ZSBpZGVhbCBpZiB0aGF0IFBBU0lEIG9ubHkgCj4gcG9pbnRzIHRvIGEgZHVtbXkgcm9vdCBwYWdl
+IGRpcmVjdG9yeSB3aXRoIG9ubHkgaW52YWxpZCBlbnRyaWVzLgo+IApJIGd1ZXNzIHRoaXMgY2Fu
+IGJlIHZlbmRvciBzcGVjaWZpYywgSW4gVlQtZCBJIHBsYW4gdG8gbWFyayBQQVNJRAplbnRyeSBu
+b3QgcHJlc2VudCBhbmQgZGlzYWJsZSBmYXVsdCByZXBvcnRpbmcgd2hpbGUgZHJhaW5pbmcgcmVt
+YWluaW5nCmFjdGl2aXRpZXMuCgo+ID4gIAo+ID4+IDQuIEl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2
+ZSB0byBiZSBhYmxlIHRvIHNldCBhICJ2b2lkICoiIGZvciBlYWNoCj4gPj4gUEFTSUQvZGV2aWNl
+IGNvbWJpbmF0aW9uIHdoaWxlIGJpbmRpbmcgdG8gYSBwcm9jZXNzIHdoaWNoIHRoZW4gY2FuCj4g
+Pj4gYmUgcXVlcmllZCBsYXRlciBvbiBiYXNlZCBvbiB0aGUgUEFTSUQuCj4gPj4gICDCoMKgwqAg
+wqDCoMKgIEUuZy4gd2hlbiB5b3UgaGF2ZSBhIHBlciBQQVNJRC9kZXZpY2Ugc3RydWN0dXJlIGFy
+b3VuZAo+ID4+IGFueXdheSwganVzdCBhZGQgYW4gZXh0cmEgZmllbGQuICAKPiA+IGlvbW11X3N2
+YV9iaW5kX2RldmljZSgpIHRha2VzIGEgImRydmRhdGEiIHBvaW50ZXIgdGhhdCBpcyBzdG9yZWQK
+PiA+IGludGVybmFsbHkgZm9yIHRoZSBQQVNJRC9kZXZpY2UgY29tYmluYXRpb24gKGlvbW11X2Jv
+bmQpLiBJdCBpcwo+ID4gcGFzc2VkIHRvIG1tX2V4aXQoKSwgYnV0IEkgaGF2ZW4ndCBhZGRlZCBh
+bnl0aGluZyBmb3IgdGhlIGRldmljZQo+ID4gZHJpdmVyIHRvIHF1ZXJ5IGl0IGJhY2suICAKPiAK
+PiBOaWNlISBMb29rcyBsaWtlIGFsbCB3ZSBuZWVkIGFkZGl0aW9uYWxseSBpcyBhIGZ1bmN0aW9u
+IHRvIHJldHJpZXZlCj4gdGhhdCBiYXNlZCBvbiB0aGUgUEFTSUQuCj4gCj4gPj4gNS4gSXQgd291
+bGQgYmUgbmljZSB0byBoYXZlIHRvIGFsbG9jYXRlIG11bHRpcGxlIFBBU0lEcyBmb3IgdGhlCj4g
+Pj4gc2FtZSBwcm9jZXNzIGFkZHJlc3Mgc3BhY2UuCj4gPj4gICDCoMKgwqAgwqDCoMKgIEUuZy4g
+c29tZSB0ZWFtcyBhdCBBTUQgd2FudCB0byB1c2UgYSBzZXBhcmF0ZSBHUFUKPiA+PiBhZGRyZXNz
+IHNwYWNlIGZvciB0aGVpciB1c2Vyc3BhY2UgY2xpZW50IGxpYnJhcnkuIEknbSBzdGlsbCB0cnlp
+bmcKPiA+PiB0byBhdm9pZCB0aGF0LCBidXQgaXQgaXMgcGVyZmVjdGx5IHBvc3NpYmxlIHRoYXQg
+d2UgYXJlIGdvaW5nIHRvCj4gPj4gbmVlZCB0aGF0LiAgCj4gPiBUd28gUEFTSURzIHBvaW50aW5n
+IHRvIHRoZSBzYW1lIHByb2Nlc3MgcGdkPyBBdCBmaXJzdCBnbGFuY2UgaXQKPiA+IHNlZW1zIGZl
+YXNpYmxlLCBtYXliZSB3aXRoIGEgZmxhZyBwYXNzZWQgdG8gYmluZCgpIGFuZCBhIGZldwo+ID4g
+Y2hhbmdlcyB0byBpbnRlcm5hbCBzdHJ1Y3R1cmVzLiBJdCB3aWxsIGR1cGxpY2F0ZSBBVEMgaW52
+YWxpZGF0aW9uCj4gPiBjb21tYW5kcyBmb3IgZWFjaCBwcm9jZXNzIGFkZHJlc3Mgc3BhY2UgY2hh
+bmdlIChtdW5tYXAgZXRjKSBzbyB5b3UKPiA+IG1pZ2h0IHRha2UgYSBwZXJmb3JtYW5jZSBoaXQu
+Cj4gPgo+ID4gSW50ZWwncyBTVk0gY29kZSBoYXMgdGhlIFNWTV9GTEFHX1BSSVZBVEVfUEFTSUQg
+d2hpY2ggc2VlbXMgc2ltaWxhcgo+ID4gdG8gd2hhdCB5b3UgZGVzY3JpYmUsIGJ1dCBJIGRvbid0
+IHBsYW4gdG8gc3VwcG9ydCBpdCBpbiB0aGlzIHNlcmllcwo+ID4gKHRoZSBpb19tbSBtb2RlbCBp
+cyBhbHJlYWR5IHByZXR0eSBjb21wbGljYXRlZCkuIEkgdGhpbmsgaXQgY2FuIGJlCj4gPiBhZGRl
+ZCB3aXRob3V0IHRvbyBtdWNoIGVmZm9ydCBpbiBhIGZ1dHVyZSBzZXJpZXMsIHRob3VnaCB3aXRo
+IGEKPiA+IGRpZmZlcmVudCBmbGFnIG5hbWUgc2luY2Ugd2UnZCBsaWtlIHRvIHVzZSAicHJpdmF0
+ZSBQQVNJRCIgZm9yCj4gPiBzb21ldGhpbmcgZWxzZQo+ID4gKGh0dHBzOi8vd3d3LnNwaW5pY3Mu
+bmV0L2xpc3RzL2RyaS1kZXZlbC9tc2cxNzcwMDcuaHRtbCkuICAKPiAKPiBUbyBiZSBob25lc3Qg
+SSBob3BlZCB0aGF0IHlvdSB3b3VsZCBzYXk6IE5vIG5ldmVyISBTbyB0aGF0IEkgaGF2ZSBhCj4g
+Z29vZCBhcmd1bWVudCB0byBwdXNoYmFjayBvbiBzdWNoIHJlcXVpcmVtZW50cyA6KQo+IAo+IEJ1
+dCBpZiBpdCdzIGRvYWJsZSBpdCB3b3VsZCBiZSBhdCBsZWFzdCBuaWNlIHRvIGhhdmUgZm9yIGRl
+YnVnZ2luZy4KPiAKPiBUaGFua3MgYSBsb3QgZm9yIHdvcmtpbmcgb24gdGhhdCwKPiBDaHJpc3Rp
+YW4uCj4gCj4gPgo+ID4gVGhhbmtzLAo+ID4gSmVhbgo+ID4gIAo+ID4+ICAgwqDCoMKgIMKgwqDC
+oCBBZGRpdGlvbmFsIHRvIHRoYXQgaXQgaXMgc29tZXRpbWVzIHF1aXRlIHVzZWZ1bCBmb3IKPiA+
+PiBkZWJ1Z2dpbmcgdG8gaXNvbGF0ZSB3aGVyZSBleGFjdGx5IGFuIGluY29ycmVjdCBhY2Nlc3Mg
+KHNlZ2ZhdWx0KQo+ID4+IGlzIGNvbWluZyBmcm9tLgo+ID4+Cj4gPj4gTGV0IG1lIGtub3cgaWYg
+dGhlcmUgYXJlIHNvbWUgcHJvYmxlbXMgd2l0aCB0aGF0LCBlc3BlY2lhbGx5IEkKPiA+PiB3YW50
+IHRvIGtub3cgaWYgdGhlcmUgaXMgcHVzaGJhY2sgb24gIzUgc28gdGhhdCBJIGNhbiBmb3J3YXJk
+Cj4gPj4gdGhhdCA6KQo+ID4+Cj4gPj4gVGhhbmtzLAo+ID4+IENocmlzdGlhbi4KPiA+PiAgCj4g
+Pj4+IFRoYW5rcywKPiA+Pj4gSmVhbiAgCj4gCgpbSmFjb2IgUGFuXQoKX19fX19fX19fX19fX19f
+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5n
+IGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5p
+bmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=
diff --git a/a/content_digest b/N1/content_digest
index 482babd..3ac1deb 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -7,181 +7,161 @@
  "ref\02fd4a0a1-1a35-bf82-df84-b995cce011d9@amd.com\0"
  "ref\065e7accd-4446-19f5-c667-c6407e89cfa6@arm.com\0"
  "ref\05bbc0332-b94b-75cc-ca42-a9b196811daf@amd.com\0"
- "ref\05bbc0332-b94b-75cc-ca42-a9b196811daf-5C7GfCeVMHo@public.gmane.org\0"
- "From\0Jacob Pan <jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>\0"
+ "From\0Jacob Pan <jacob.jun.pan@linux.intel.com>\0"
  "Subject\0Re: [PATCH v2 01/40] iommu: Introduce Shared Virtual Addressing API\0"
  "Date\0Fri, 7 Sep 2018 14:25:04 -0700\0"
- "To\0Christian K\303\266nig <christian.koenig-5C7GfCeVMHo@public.gmane.org>\0"
- "Cc\0xieyisheng1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org <xieyisheng1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>"
-  ilias.apalodimas-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org <ilias.apalodimas-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
-  kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
-  linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
-  Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>
-  Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
-  okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
-  linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>
-  ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org <ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
-  Jean-Philippe Brucker <jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
-  linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
-  rfranz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org <rfranz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
-  devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
-  kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org <kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
-  rgummal-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org <rgummal-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
-  linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
-  dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
- " liubo95-hv44wF8Li93QT0dZR+AlfA@public.gmane.org <liubo95@hua>\0"
+ "To\0Christian K\303\266nig <christian.koenig@amd.com>\0"
+ "Cc\0xieyisheng1@huawei.com <xieyisheng1@huawei.com>"
+  ilias.apalodimas@linaro.org <ilias.apalodimas@linaro.org>
+  kvm@vger.kernel.org <kvm@vger.kernel.org>
+  linux-pci@vger.kernel.org <linux-pci@vger.kernel.org>
+  xuzaibo@huawei.com <xuzaibo@huawei.com>
+  jonathan.cameron@huawei.com <jonathan.cameron@huawei.com>
+  Will Deacon <Will.Deacon@arm.com>
+  Michal Hocko <mhocko@kernel.org>
+  okaya@codeaurora.org <okaya@codeaurora.org>
+  linux-mm@kvack.org <linux-mm@kvack.org>
+  yi.l.liu@intel.com <yi.l.liu@intel.com>
+  ashok.raj@intel.com <ashok.raj@intel.com>
+  Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
+  tn@semihalf.com <tn@semihalf.com>
+  joro@8bytes.org <joro@8bytes.org>
+  robdclark@gmail.com <robdclark@gmail.com>
+  bharatku@xilinx.com <bharatku@xilinx.com>
+  linux-acpi@vger.kernel.org <linux-acpi@vger.kernel.org>
+  liudongdong3@huawei.com <liudongdong3@huawei.com>
+  rfranz@cavium.com <rfranz@cavium.com>
+  devicetree@vger.kernel.org <devicetree@vger.kernel.org>
+  kevin.tian@intel.com <kevin.tian@intel.com>
+  jacob.jun.pan@linux.intel.com
+  Auger Eric <eric.auger@redhat.com>
+  jcrouse@codeaurora.org <jcrouse@codeaurora.org>
+  rgummal@xilinx.com <rgummal@xilinx.com>
+  thunder.leizhen@huawei.com <thunder.leizhen@huawei.com>
+  linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>
+  shunyong.yang@hxt-semitech.com <shunyong.yang@hxt-semitech.com>
+  dwmw2@infradead.org <dwmw2@infradead.org>
+  liubo95@huawei.com <liubo95@huawei.com>
+  alex.williamson@redhat.com <alex.williamson@redhat.com>
+  iommu@lists.linux-foundation.org <iommu@lists.linux-foundation.org>
+  Robin Murphy <Robin.Murphy@arm.com>
+  nwatters@codeaurora.org <nwatters@codeaurora.org>
+ " baolu.lu@linux.intel.com <baolu.lu@linux.intel.com>\0"
  "\00:1\0"
  "b\0"
- "On Fri, 7 Sep 2018 20:02:54 +0200\n"
- "Christian K\303\266nig <christian.koenig@amd.com> wrote:\n"
- "\n"
- "> Am 07.09.2018 um 17:45 schrieb Jean-Philippe Brucker:\n"
- "> > On 07/09/2018 09:55, Christian K\303\266nig wrote:  \n"
- "> >> I will take this as an opportunity to summarize some of the\n"
- "> >> requirements we have for PASID management from the amdgpu driver\n"
- "> >> point of view:  \n"
- "> > That's incredibly useful, thanks :)\n"
- "> >  \n"
- "> >> 1. We need to be able to allocate PASID between 1 and some\n"
- "> >> maximum. Zero is reserved as far as I know, but we don't necessary\n"
- "> >> need a minimum.  \n"
- ">  [...]  \n"
- "> >> 2. We need to be able to allocate PASIDs without a process address\n"
- "> >> space backing it. E.g. our hardware uses PASIDs even without\n"
- "> >> Shared Virtual Addressing enabled to distinct clients from each\n"
- "> >> other. Would be a pity if we need to still have a separate PASID\n"
- "> >> handling because the system wide is only available when IOMMU is\n"
- "> >> turned on.  \n"
- ">  [...]  \n"
- "> \n"
- "> I agree on that.\n"
- "> \n"
- "> > iommu-sva expects everywhere that the device has an iommu_domain,\n"
- "> > it's the first thing we check on entry. Bypassing all of this would\n"
- "> > call idr_alloc() directly, and wouldn't have any code in common\n"
- "> > with the current iommu-sva. So it seems like you need a layer on\n"
- "> > top of iommu-sva calling idr_alloc() when an IOMMU isn't present,\n"
- "> > but I don't think it should be in drivers/iommu/  \n"
- "> \n"
- "> In this case I question if the PASID handling should be under \n"
- "> drivers/iommu at all.\n"
- "> \n"
- "> See I can have a mix of VM context which are bound to processes (some \n"
- "> few) and VM contexts which are standalone and doesn't care for a\n"
- "> process address space. But for each VM context I need a distinct\n"
- "> PASID for the hardware to work.\n"
- "> \n"
- "> I can live if we say if IOMMU is completely disabled we use a simple\n"
- "> ida to allocate them, but when IOMMU is enabled I certainly need a\n"
- "> way to reserve a PASID without an associated process.\n"
- "> \n"
- "VT-d would also have such requirement. There is a virtual command\n"
- "register for allocate and free PASID for VM use. When that PASID\n"
- "allocation request gets propagated to the host IOMMU driver, we need to\n"
- "allocate PASID w/o mm.\n"
- "\n"
- "If the PASID allocation is done via VFIO, can we have FD to track PASID\n"
- "life cycle instead of mm_exit()? i.e. all FDs get closed before\n"
- "mm_exit, I assume?\n"
- "\n"
- "> >> 3. Even after destruction of a process address space we need some\n"
- "> >> grace period before a PASID is reused because it can be that the\n"
- "> >> specific PASID is still in some hardware queues etc...\n"
- "> >>   \302\240\302\240\302\240 \302\240\302\240\302\240 At bare minimum all device drivers using process binding\n"
- "> >> need to explicitly note to the core when they are done with a\n"
- "> >> PASID.  \n"
- "> > Right, much of the horribleness in iommu-sva deals with this:\n"
- "> >\n"
- "> > The process dies, iommu-sva is notified and calls the mm_exit()\n"
- "> > function passed by the device driver to iommu_sva_device_init(). In\n"
- "> > mm_exit() the device driver needs to clear any reference to the\n"
- "> > PASID in hardware and in its own structures. When the device driver\n"
- "> > returns from mm_exit(), it effectively tells the core that it has\n"
- "> > finished using the PASID, and iommu-sva can reuse the PASID for\n"
- "> > another process. mm_exit() is allowed to block, so the device\n"
- "> > driver has time to clean up and flush the queues.\n"
- "> >\n"
- "> > If the device driver finishes using the PASID before the process\n"
- "> > exits, it just calls unbind().  \n"
- "> \n"
- "> Exactly that's what Michal Hocko is probably going to not like at all.\n"
- "> \n"
- "> Can we have a different approach where each driver is informed by the \n"
- "> mm_exit(), but needs to explicitly call unbind() before a PASID is\n"
- "> reused?\n"
- "> \n"
- "> During that teardown transition it would be ideal if that PASID only \n"
- "> points to a dummy root page directory with only invalid entries.\n"
- "> \n"
- "I guess this can be vendor specific, In VT-d I plan to mark PASID\n"
- "entry not present and disable fault reporting while draining remaining\n"
- "activities.\n"
- "\n"
- "> >  \n"
- "> >> 4. It would be nice to have to be able to set a \"void *\" for each\n"
- "> >> PASID/device combination while binding to a process which then can\n"
- "> >> be queried later on based on the PASID.\n"
- "> >>   \302\240\302\240\302\240 \302\240\302\240\302\240 E.g. when you have a per PASID/device structure around\n"
- "> >> anyway, just add an extra field.  \n"
- "> > iommu_sva_bind_device() takes a \"drvdata\" pointer that is stored\n"
- "> > internally for the PASID/device combination (iommu_bond). It is\n"
- "> > passed to mm_exit(), but I haven't added anything for the device\n"
- "> > driver to query it back.  \n"
- "> \n"
- "> Nice! Looks like all we need additionally is a function to retrieve\n"
- "> that based on the PASID.\n"
- "> \n"
- "> >> 5. It would be nice to have to allocate multiple PASIDs for the\n"
- "> >> same process address space.\n"
- "> >>   \302\240\302\240\302\240 \302\240\302\240\302\240 E.g. some teams at AMD want to use a separate GPU\n"
- "> >> address space for their userspace client library. I'm still trying\n"
- "> >> to avoid that, but it is perfectly possible that we are going to\n"
- "> >> need that.  \n"
- "> > Two PASIDs pointing to the same process pgd? At first glance it\n"
- "> > seems feasible, maybe with a flag passed to bind() and a few\n"
- "> > changes to internal structures. It will duplicate ATC invalidation\n"
- "> > commands for each process address space change (munmap etc) so you\n"
- "> > might take a performance hit.\n"
- "> >\n"
- "> > Intel's SVM code has the SVM_FLAG_PRIVATE_PASID which seems similar\n"
- "> > to what you describe, but I don't plan to support it in this series\n"
- "> > (the io_mm model is already pretty complicated). I think it can be\n"
- "> > added without too much effort in a future series, though with a\n"
- "> > different flag name since we'd like to use \"private PASID\" for\n"
- "> > something else\n"
- "> > (https://www.spinics.net/lists/dri-devel/msg177007.html).  \n"
- "> \n"
- "> To be honest I hoped that you would say: No never! So that I have a\n"
- "> good argument to pushback on such requirements :)\n"
- "> \n"
- "> But if it's doable it would be at least nice to have for debugging.\n"
- "> \n"
- "> Thanks a lot for working on that,\n"
- "> Christian.\n"
- "> \n"
- "> >\n"
- "> > Thanks,\n"
- "> > Jean\n"
- "> >  \n"
- "> >>   \302\240\302\240\302\240 \302\240\302\240\302\240 Additional to that it is sometimes quite useful for\n"
- "> >> debugging to isolate where exactly an incorrect access (segfault)\n"
- "> >> is coming from.\n"
- "> >>\n"
- "> >> Let me know if there are some problems with that, especially I\n"
- "> >> want to know if there is pushback on #5 so that I can forward\n"
- "> >> that :)\n"
- "> >>\n"
- "> >> Thanks,\n"
- "> >> Christian.\n"
- "> >>  \n"
- "> >>> Thanks,\n"
- "> >>> Jean  \n"
- "> \n"
- "\n"
- "[Jacob Pan]\n"
- "_______________________________________________\n"
- "iommu mailing list\n"
- "iommu@lists.linux-foundation.org\n"
- https://lists.linuxfoundation.org/mailman/listinfo/iommu
+ "T24gRnJpLCA3IFNlcCAyMDE4IDIwOjAyOjU0ICswMjAwCkNocmlzdGlhbiBLw7ZuaWcgPGNocmlz\n"
+ "dGlhbi5rb2VuaWdAYW1kLmNvbT4gd3JvdGU6Cgo+IEFtIDA3LjA5LjIwMTggdW0gMTc6NDUgc2No\n"
+ "cmllYiBKZWFuLVBoaWxpcHBlIEJydWNrZXI6Cj4gPiBPbiAwNy8wOS8yMDE4IDA5OjU1LCBDaHJp\n"
+ "c3RpYW4gS8O2bmlnIHdyb3RlOiAgCj4gPj4gSSB3aWxsIHRha2UgdGhpcyBhcyBhbiBvcHBvcnR1\n"
+ "bml0eSB0byBzdW1tYXJpemUgc29tZSBvZiB0aGUKPiA+PiByZXF1aXJlbWVudHMgd2UgaGF2ZSBm\n"
+ "b3IgUEFTSUQgbWFuYWdlbWVudCBmcm9tIHRoZSBhbWRncHUgZHJpdmVyCj4gPj4gcG9pbnQgb2Yg\n"
+ "dmlldzogIAo+ID4gVGhhdCdzIGluY3JlZGlibHkgdXNlZnVsLCB0aGFua3MgOikKPiA+ICAKPiA+\n"
+ "PiAxLiBXZSBuZWVkIHRvIGJlIGFibGUgdG8gYWxsb2NhdGUgUEFTSUQgYmV0d2VlbiAxIGFuZCBz\n"
+ "b21lCj4gPj4gbWF4aW11bS4gWmVybyBpcyByZXNlcnZlZCBhcyBmYXIgYXMgSSBrbm93LCBidXQg\n"
+ "d2UgZG9uJ3QgbmVjZXNzYXJ5Cj4gPj4gbmVlZCBhIG1pbmltdW0uICAKPiAgWy4uLl0gIAo+ID4+\n"
+ "IDIuIFdlIG5lZWQgdG8gYmUgYWJsZSB0byBhbGxvY2F0ZSBQQVNJRHMgd2l0aG91dCBhIHByb2Nl\n"
+ "c3MgYWRkcmVzcwo+ID4+IHNwYWNlIGJhY2tpbmcgaXQuIEUuZy4gb3VyIGhhcmR3YXJlIHVzZXMg\n"
+ "UEFTSURzIGV2ZW4gd2l0aG91dAo+ID4+IFNoYXJlZCBWaXJ0dWFsIEFkZHJlc3NpbmcgZW5hYmxl\n"
+ "ZCB0byBkaXN0aW5jdCBjbGllbnRzIGZyb20gZWFjaAo+ID4+IG90aGVyLiBXb3VsZCBiZSBhIHBp\n"
+ "dHkgaWYgd2UgbmVlZCB0byBzdGlsbCBoYXZlIGEgc2VwYXJhdGUgUEFTSUQKPiA+PiBoYW5kbGlu\n"
+ "ZyBiZWNhdXNlIHRoZSBzeXN0ZW0gd2lkZSBpcyBvbmx5IGF2YWlsYWJsZSB3aGVuIElPTU1VIGlz\n"
+ "Cj4gPj4gdHVybmVkIG9uLiAgCj4gIFsuLi5dICAKPiAKPiBJIGFncmVlIG9uIHRoYXQuCj4gCj4g\n"
+ "PiBpb21tdS1zdmEgZXhwZWN0cyBldmVyeXdoZXJlIHRoYXQgdGhlIGRldmljZSBoYXMgYW4gaW9t\n"
+ "bXVfZG9tYWluLAo+ID4gaXQncyB0aGUgZmlyc3QgdGhpbmcgd2UgY2hlY2sgb24gZW50cnkuIEJ5\n"
+ "cGFzc2luZyBhbGwgb2YgdGhpcyB3b3VsZAo+ID4gY2FsbCBpZHJfYWxsb2MoKSBkaXJlY3RseSwg\n"
+ "YW5kIHdvdWxkbid0IGhhdmUgYW55IGNvZGUgaW4gY29tbW9uCj4gPiB3aXRoIHRoZSBjdXJyZW50\n"
+ "IGlvbW11LXN2YS4gU28gaXQgc2VlbXMgbGlrZSB5b3UgbmVlZCBhIGxheWVyIG9uCj4gPiB0b3Ag\n"
+ "b2YgaW9tbXUtc3ZhIGNhbGxpbmcgaWRyX2FsbG9jKCkgd2hlbiBhbiBJT01NVSBpc24ndCBwcmVz\n"
+ "ZW50LAo+ID4gYnV0IEkgZG9uJ3QgdGhpbmsgaXQgc2hvdWxkIGJlIGluIGRyaXZlcnMvaW9tbXUv\n"
+ "ICAKPiAKPiBJbiB0aGlzIGNhc2UgSSBxdWVzdGlvbiBpZiB0aGUgUEFTSUQgaGFuZGxpbmcgc2hv\n"
+ "dWxkIGJlIHVuZGVyIAo+IGRyaXZlcnMvaW9tbXUgYXQgYWxsLgo+IAo+IFNlZSBJIGNhbiBoYXZl\n"
+ "IGEgbWl4IG9mIFZNIGNvbnRleHQgd2hpY2ggYXJlIGJvdW5kIHRvIHByb2Nlc3NlcyAoc29tZSAK\n"
+ "PiBmZXcpIGFuZCBWTSBjb250ZXh0cyB3aGljaCBhcmUgc3RhbmRhbG9uZSBhbmQgZG9lc24ndCBj\n"
+ "YXJlIGZvciBhCj4gcHJvY2VzcyBhZGRyZXNzIHNwYWNlLiBCdXQgZm9yIGVhY2ggVk0gY29udGV4\n"
+ "dCBJIG5lZWQgYSBkaXN0aW5jdAo+IFBBU0lEIGZvciB0aGUgaGFyZHdhcmUgdG8gd29yay4KPiAK\n"
+ "PiBJIGNhbiBsaXZlIGlmIHdlIHNheSBpZiBJT01NVSBpcyBjb21wbGV0ZWx5IGRpc2FibGVkIHdl\n"
+ "IHVzZSBhIHNpbXBsZQo+IGlkYSB0byBhbGxvY2F0ZSB0aGVtLCBidXQgd2hlbiBJT01NVSBpcyBl\n"
+ "bmFibGVkIEkgY2VydGFpbmx5IG5lZWQgYQo+IHdheSB0byByZXNlcnZlIGEgUEFTSUQgd2l0aG91\n"
+ "dCBhbiBhc3NvY2lhdGVkIHByb2Nlc3MuCj4gClZULWQgd291bGQgYWxzbyBoYXZlIHN1Y2ggcmVx\n"
+ "dWlyZW1lbnQuIFRoZXJlIGlzIGEgdmlydHVhbCBjb21tYW5kCnJlZ2lzdGVyIGZvciBhbGxvY2F0\n"
+ "ZSBhbmQgZnJlZSBQQVNJRCBmb3IgVk0gdXNlLiBXaGVuIHRoYXQgUEFTSUQKYWxsb2NhdGlvbiBy\n"
+ "ZXF1ZXN0IGdldHMgcHJvcGFnYXRlZCB0byB0aGUgaG9zdCBJT01NVSBkcml2ZXIsIHdlIG5lZWQg\n"
+ "dG8KYWxsb2NhdGUgUEFTSUQgdy9vIG1tLgoKSWYgdGhlIFBBU0lEIGFsbG9jYXRpb24gaXMgZG9u\n"
+ "ZSB2aWEgVkZJTywgY2FuIHdlIGhhdmUgRkQgdG8gdHJhY2sgUEFTSUQKbGlmZSBjeWNsZSBpbnN0\n"
+ "ZWFkIG9mIG1tX2V4aXQoKT8gaS5lLiBhbGwgRkRzIGdldCBjbG9zZWQgYmVmb3JlCm1tX2V4aXQs\n"
+ "IEkgYXNzdW1lPwoKPiA+PiAzLiBFdmVuIGFmdGVyIGRlc3RydWN0aW9uIG9mIGEgcHJvY2VzcyBh\n"
+ "ZGRyZXNzIHNwYWNlIHdlIG5lZWQgc29tZQo+ID4+IGdyYWNlIHBlcmlvZCBiZWZvcmUgYSBQQVNJ\n"
+ "RCBpcyByZXVzZWQgYmVjYXVzZSBpdCBjYW4gYmUgdGhhdCB0aGUKPiA+PiBzcGVjaWZpYyBQQVNJ\n"
+ "RCBpcyBzdGlsbCBpbiBzb21lIGhhcmR3YXJlIHF1ZXVlcyBldGMuLi4KPiA+PiAgIMKgwqDCoCDC\n"
+ "oMKgwqAgQXQgYmFyZSBtaW5pbXVtIGFsbCBkZXZpY2UgZHJpdmVycyB1c2luZyBwcm9jZXNzIGJp\n"
+ "bmRpbmcKPiA+PiBuZWVkIHRvIGV4cGxpY2l0bHkgbm90ZSB0byB0aGUgY29yZSB3aGVuIHRoZXkg\n"
+ "YXJlIGRvbmUgd2l0aCBhCj4gPj4gUEFTSUQuICAKPiA+IFJpZ2h0LCBtdWNoIG9mIHRoZSBob3Jy\n"
+ "aWJsZW5lc3MgaW4gaW9tbXUtc3ZhIGRlYWxzIHdpdGggdGhpczoKPiA+Cj4gPiBUaGUgcHJvY2Vz\n"
+ "cyBkaWVzLCBpb21tdS1zdmEgaXMgbm90aWZpZWQgYW5kIGNhbGxzIHRoZSBtbV9leGl0KCkKPiA+\n"
+ "IGZ1bmN0aW9uIHBhc3NlZCBieSB0aGUgZGV2aWNlIGRyaXZlciB0byBpb21tdV9zdmFfZGV2aWNl\n"
+ "X2luaXQoKS4gSW4KPiA+IG1tX2V4aXQoKSB0aGUgZGV2aWNlIGRyaXZlciBuZWVkcyB0byBjbGVh\n"
+ "ciBhbnkgcmVmZXJlbmNlIHRvIHRoZQo+ID4gUEFTSUQgaW4gaGFyZHdhcmUgYW5kIGluIGl0cyBv\n"
+ "d24gc3RydWN0dXJlcy4gV2hlbiB0aGUgZGV2aWNlIGRyaXZlcgo+ID4gcmV0dXJucyBmcm9tIG1t\n"
+ "X2V4aXQoKSwgaXQgZWZmZWN0aXZlbHkgdGVsbHMgdGhlIGNvcmUgdGhhdCBpdCBoYXMKPiA+IGZp\n"
+ "bmlzaGVkIHVzaW5nIHRoZSBQQVNJRCwgYW5kIGlvbW11LXN2YSBjYW4gcmV1c2UgdGhlIFBBU0lE\n"
+ "IGZvcgo+ID4gYW5vdGhlciBwcm9jZXNzLiBtbV9leGl0KCkgaXMgYWxsb3dlZCB0byBibG9jaywg\n"
+ "c28gdGhlIGRldmljZQo+ID4gZHJpdmVyIGhhcyB0aW1lIHRvIGNsZWFuIHVwIGFuZCBmbHVzaCB0\n"
+ "aGUgcXVldWVzLgo+ID4KPiA+IElmIHRoZSBkZXZpY2UgZHJpdmVyIGZpbmlzaGVzIHVzaW5nIHRo\n"
+ "ZSBQQVNJRCBiZWZvcmUgdGhlIHByb2Nlc3MKPiA+IGV4aXRzLCBpdCBqdXN0IGNhbGxzIHVuYmlu\n"
+ "ZCgpLiAgCj4gCj4gRXhhY3RseSB0aGF0J3Mgd2hhdCBNaWNoYWwgSG9ja28gaXMgcHJvYmFibHkg\n"
+ "Z29pbmcgdG8gbm90IGxpa2UgYXQgYWxsLgo+IAo+IENhbiB3ZSBoYXZlIGEgZGlmZmVyZW50IGFw\n"
+ "cHJvYWNoIHdoZXJlIGVhY2ggZHJpdmVyIGlzIGluZm9ybWVkIGJ5IHRoZSAKPiBtbV9leGl0KCks\n"
+ "IGJ1dCBuZWVkcyB0byBleHBsaWNpdGx5IGNhbGwgdW5iaW5kKCkgYmVmb3JlIGEgUEFTSUQgaXMK\n"
+ "PiByZXVzZWQ/Cj4gCj4gRHVyaW5nIHRoYXQgdGVhcmRvd24gdHJhbnNpdGlvbiBpdCB3b3VsZCBi\n"
+ "ZSBpZGVhbCBpZiB0aGF0IFBBU0lEIG9ubHkgCj4gcG9pbnRzIHRvIGEgZHVtbXkgcm9vdCBwYWdl\n"
+ "IGRpcmVjdG9yeSB3aXRoIG9ubHkgaW52YWxpZCBlbnRyaWVzLgo+IApJIGd1ZXNzIHRoaXMgY2Fu\n"
+ "IGJlIHZlbmRvciBzcGVjaWZpYywgSW4gVlQtZCBJIHBsYW4gdG8gbWFyayBQQVNJRAplbnRyeSBu\n"
+ "b3QgcHJlc2VudCBhbmQgZGlzYWJsZSBmYXVsdCByZXBvcnRpbmcgd2hpbGUgZHJhaW5pbmcgcmVt\n"
+ "YWluaW5nCmFjdGl2aXRpZXMuCgo+ID4gIAo+ID4+IDQuIEl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2\n"
+ "ZSB0byBiZSBhYmxlIHRvIHNldCBhICJ2b2lkICoiIGZvciBlYWNoCj4gPj4gUEFTSUQvZGV2aWNl\n"
+ "IGNvbWJpbmF0aW9uIHdoaWxlIGJpbmRpbmcgdG8gYSBwcm9jZXNzIHdoaWNoIHRoZW4gY2FuCj4g\n"
+ "Pj4gYmUgcXVlcmllZCBsYXRlciBvbiBiYXNlZCBvbiB0aGUgUEFTSUQuCj4gPj4gICDCoMKgwqAg\n"
+ "wqDCoMKgIEUuZy4gd2hlbiB5b3UgaGF2ZSBhIHBlciBQQVNJRC9kZXZpY2Ugc3RydWN0dXJlIGFy\n"
+ "b3VuZAo+ID4+IGFueXdheSwganVzdCBhZGQgYW4gZXh0cmEgZmllbGQuICAKPiA+IGlvbW11X3N2\n"
+ "YV9iaW5kX2RldmljZSgpIHRha2VzIGEgImRydmRhdGEiIHBvaW50ZXIgdGhhdCBpcyBzdG9yZWQK\n"
+ "PiA+IGludGVybmFsbHkgZm9yIHRoZSBQQVNJRC9kZXZpY2UgY29tYmluYXRpb24gKGlvbW11X2Jv\n"
+ "bmQpLiBJdCBpcwo+ID4gcGFzc2VkIHRvIG1tX2V4aXQoKSwgYnV0IEkgaGF2ZW4ndCBhZGRlZCBh\n"
+ "bnl0aGluZyBmb3IgdGhlIGRldmljZQo+ID4gZHJpdmVyIHRvIHF1ZXJ5IGl0IGJhY2suICAKPiAK\n"
+ "PiBOaWNlISBMb29rcyBsaWtlIGFsbCB3ZSBuZWVkIGFkZGl0aW9uYWxseSBpcyBhIGZ1bmN0aW9u\n"
+ "IHRvIHJldHJpZXZlCj4gdGhhdCBiYXNlZCBvbiB0aGUgUEFTSUQuCj4gCj4gPj4gNS4gSXQgd291\n"
+ "bGQgYmUgbmljZSB0byBoYXZlIHRvIGFsbG9jYXRlIG11bHRpcGxlIFBBU0lEcyBmb3IgdGhlCj4g\n"
+ "Pj4gc2FtZSBwcm9jZXNzIGFkZHJlc3Mgc3BhY2UuCj4gPj4gICDCoMKgwqAgwqDCoMKgIEUuZy4g\n"
+ "c29tZSB0ZWFtcyBhdCBBTUQgd2FudCB0byB1c2UgYSBzZXBhcmF0ZSBHUFUKPiA+PiBhZGRyZXNz\n"
+ "IHNwYWNlIGZvciB0aGVpciB1c2Vyc3BhY2UgY2xpZW50IGxpYnJhcnkuIEknbSBzdGlsbCB0cnlp\n"
+ "bmcKPiA+PiB0byBhdm9pZCB0aGF0LCBidXQgaXQgaXMgcGVyZmVjdGx5IHBvc3NpYmxlIHRoYXQg\n"
+ "d2UgYXJlIGdvaW5nIHRvCj4gPj4gbmVlZCB0aGF0LiAgCj4gPiBUd28gUEFTSURzIHBvaW50aW5n\n"
+ "IHRvIHRoZSBzYW1lIHByb2Nlc3MgcGdkPyBBdCBmaXJzdCBnbGFuY2UgaXQKPiA+IHNlZW1zIGZl\n"
+ "YXNpYmxlLCBtYXliZSB3aXRoIGEgZmxhZyBwYXNzZWQgdG8gYmluZCgpIGFuZCBhIGZldwo+ID4g\n"
+ "Y2hhbmdlcyB0byBpbnRlcm5hbCBzdHJ1Y3R1cmVzLiBJdCB3aWxsIGR1cGxpY2F0ZSBBVEMgaW52\n"
+ "YWxpZGF0aW9uCj4gPiBjb21tYW5kcyBmb3IgZWFjaCBwcm9jZXNzIGFkZHJlc3Mgc3BhY2UgY2hh\n"
+ "bmdlIChtdW5tYXAgZXRjKSBzbyB5b3UKPiA+IG1pZ2h0IHRha2UgYSBwZXJmb3JtYW5jZSBoaXQu\n"
+ "Cj4gPgo+ID4gSW50ZWwncyBTVk0gY29kZSBoYXMgdGhlIFNWTV9GTEFHX1BSSVZBVEVfUEFTSUQg\n"
+ "d2hpY2ggc2VlbXMgc2ltaWxhcgo+ID4gdG8gd2hhdCB5b3UgZGVzY3JpYmUsIGJ1dCBJIGRvbid0\n"
+ "IHBsYW4gdG8gc3VwcG9ydCBpdCBpbiB0aGlzIHNlcmllcwo+ID4gKHRoZSBpb19tbSBtb2RlbCBp\n"
+ "cyBhbHJlYWR5IHByZXR0eSBjb21wbGljYXRlZCkuIEkgdGhpbmsgaXQgY2FuIGJlCj4gPiBhZGRl\n"
+ "ZCB3aXRob3V0IHRvbyBtdWNoIGVmZm9ydCBpbiBhIGZ1dHVyZSBzZXJpZXMsIHRob3VnaCB3aXRo\n"
+ "IGEKPiA+IGRpZmZlcmVudCBmbGFnIG5hbWUgc2luY2Ugd2UnZCBsaWtlIHRvIHVzZSAicHJpdmF0\n"
+ "ZSBQQVNJRCIgZm9yCj4gPiBzb21ldGhpbmcgZWxzZQo+ID4gKGh0dHBzOi8vd3d3LnNwaW5pY3Mu\n"
+ "bmV0L2xpc3RzL2RyaS1kZXZlbC9tc2cxNzcwMDcuaHRtbCkuICAKPiAKPiBUbyBiZSBob25lc3Qg\n"
+ "SSBob3BlZCB0aGF0IHlvdSB3b3VsZCBzYXk6IE5vIG5ldmVyISBTbyB0aGF0IEkgaGF2ZSBhCj4g\n"
+ "Z29vZCBhcmd1bWVudCB0byBwdXNoYmFjayBvbiBzdWNoIHJlcXVpcmVtZW50cyA6KQo+IAo+IEJ1\n"
+ "dCBpZiBpdCdzIGRvYWJsZSBpdCB3b3VsZCBiZSBhdCBsZWFzdCBuaWNlIHRvIGhhdmUgZm9yIGRl\n"
+ "YnVnZ2luZy4KPiAKPiBUaGFua3MgYSBsb3QgZm9yIHdvcmtpbmcgb24gdGhhdCwKPiBDaHJpc3Rp\n"
+ "YW4uCj4gCj4gPgo+ID4gVGhhbmtzLAo+ID4gSmVhbgo+ID4gIAo+ID4+ICAgwqDCoMKgIMKgwqDC\n"
+ "oCBBZGRpdGlvbmFsIHRvIHRoYXQgaXQgaXMgc29tZXRpbWVzIHF1aXRlIHVzZWZ1bCBmb3IKPiA+\n"
+ "PiBkZWJ1Z2dpbmcgdG8gaXNvbGF0ZSB3aGVyZSBleGFjdGx5IGFuIGluY29ycmVjdCBhY2Nlc3Mg\n"
+ "KHNlZ2ZhdWx0KQo+ID4+IGlzIGNvbWluZyBmcm9tLgo+ID4+Cj4gPj4gTGV0IG1lIGtub3cgaWYg\n"
+ "dGhlcmUgYXJlIHNvbWUgcHJvYmxlbXMgd2l0aCB0aGF0LCBlc3BlY2lhbGx5IEkKPiA+PiB3YW50\n"
+ "IHRvIGtub3cgaWYgdGhlcmUgaXMgcHVzaGJhY2sgb24gIzUgc28gdGhhdCBJIGNhbiBmb3J3YXJk\n"
+ "Cj4gPj4gdGhhdCA6KQo+ID4+Cj4gPj4gVGhhbmtzLAo+ID4+IENocmlzdGlhbi4KPiA+PiAgCj4g\n"
+ "Pj4+IFRoYW5rcywKPiA+Pj4gSmVhbiAgCj4gCgpbSmFjb2IgUGFuXQoKX19fX19fX19fX19fX19f\n"
+ "X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5n\n"
+ "IGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5p\n"
+ bmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=
 
-9c3476ba1dc0c94633a1de6723708f8bf166d6f78911508ed309ab479a95cf90
+0789419c88d36ce33829296559d28ac571ef219337856ab860801799a3eb85c1
