Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <8f749cd0-9a04-7c72-6a4f-a42d501e1489@amd.com>
Date:   Mon, 15 Aug 2022 13:28:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH v1] drm/ttm: Refcount allocated tail pages
Content-Language: en-US
To:     Dmitry Osipenko <dmitry.osipenko@collabora.com>,
        David Airlie <airlied@linux.ie>, Huang Rui <ray.huang@amd.com>,
        Daniel Vetter <daniel@ffwll.ch>,
        Trigger Huang <Trigger.Huang@gmail.com>,
        Gert Wollny <gert.wollny@collabora.com>,
        Antonio Caggiano <antonio.caggiano@collabora.com>
Cc:     dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        Dmitry Osipenko <digetx@gmail.com>, kvm@vger.kernel.org,
        kernel@collabora.com, virtualization@lists.linux-foundation.org
References: <20220815095423.11131-1-dmitry.osipenko@collabora.com>
 <8230a356-be38-f228-4a8e-95124e8e8db6@amd.com>
 <134bce02-58d6-8553-bb73-42dfda18a595@collabora.com>
 <8caf3008-dcf3-985a-631e-e019b277c6f0@amd.com>
 <4fcc4739-2da9-1b89-209c-876129604d7d@amd.com>
 <14be3b22-1d60-732b-c695-ddacc6b21055@collabora.com>
 <2df57a30-2afb-23dc-c7f5-f61c113dd5b4@collabora.com>
 <57562db8-bacf-e82d-8417-ab6343c1d2fa@amd.com>
 <86a87de8-24a9-3c53-3ac7-612ca97e41df@collabora.com>
From:   =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
In-Reply-To: <86a87de8-24a9-3c53-3ac7-612ca97e41df@collabora.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TDlqV2c5MGM2bTcwOXY0MXU5ZkRObzhoUDZxNWNMZklyMmdNMnA3TGNuaXdU?=
 =?utf-8?B?bnhXQXFlc2ZJYnk0SGVrY3BWdTZlbDZDWnR0TmZNU0hFSk84SlhtYS9BTTV0?=
 =?utf-8?B?cjdCTmN6K2d0UU1hYXB2MWluOHFUNTR4aTV3SVIzVS92aU02dHVoRjQwNXVJ?=
 =?utf-8?B?YkRiamtMNzZqYUNGMWtxZkJMdUp5TFFXSEFTRDFyV3kzSGUxakM0Y3BPNnJX?=
 =?utf-8?B?Q2d6b0d5NTB0d2VqZmV6bDFieDhnNzBsQ2VJbDR0N0xrZmxBTm5VLzZXQ1JL?=
 =?utf-8?B?Tm4zY0VjM1F3MElUSG1kWGsxNklhSFhGVTJUbjVmbkU2c0R0cmpQV1FTRW9x?=
 =?utf-8?B?d2pqQVV5UWEzZmpNcW9CMFhuZThuYmR2am51ZjI0bXIrZFlsQnRLclNnTTdu?=
 =?utf-8?B?OG1FSm1IN0hxd2pZM3E1dmxlV0YrLzBJQVpOSHErQjJlUmM3K0xYdkprYkh1?=
 =?utf-8?B?VmZCeE9YcTNUcWpoOGh2M0dDNWVpYkc5Ym9nYjFXdktGS0VVenV1ZGYxRExM?=
 =?utf-8?B?c2ZSTjcrUWVINWVDd2F5OUhjNDVIcVV5SUhqT1pqSzIrT0k5SkZaY2JBUGJ0?=
 =?utf-8?B?ZjRBclZRdWNqY2t6MURrOVJYaFNzY21COXNSdjljdVVqTWJCNWJFTkhLbjU5?=
 =?utf-8?B?TTdyMFFEQko4dE95SWJMdjNia2VzcTVkeTk1NEFUTmpjZ2dSR0Y5dWROV1pV?=
 =?utf-8?B?bm5UZEhISElaT2hpUHZIN1Z2SUx5Y20wNy8zTzUwSFBsYzVDcjhQVlRLYld2?=
 =?utf-8?B?VDhvV2FISjZlQ0RaSHdtd01mcTBuSndOL1NGNFJMcU1qZThRZ3lmOHJOY1Zt?=
 =?utf-8?B?NmdIUGVTRG5IWkNaTU11UUErY0JySzQzKy9vUnlUK2ZnTnNSNDNkd1FRei9n?=
 =?utf-8?B?YzVJN2k5Ly8xTk5SR3FBYzV3dExYcm5aWFZ2bTZRc01lbEd5T3pPTjJYM1pz?=
 =?utf-8?B?VHh1SDRXOXdGVkx3OFNhZTVPU2I3WjZWYk5MNWpZTkpUMlBYNGh5bUVwYlNy?=
 =?utf-8?B?eGlrMmoxT2diWGJzckNsc2N2VlduSXRpREdSOGlSNFUybVRmTEZwNDhQMWJn?=
 =?utf-8?B?dDBoVWJ0L1lWTFJNclhHODQvenZWVG50ajNBWGNQVDlZaE9ZdXgyODBhK1Za?=
 =?utf-8?B?WDRsbHRXd1Y3MjFjeEJCcVQ2czZIRlZ4b2dHZE9zUDFNck5kMTVqVFdMSTdk?=
 =?utf-8?B?SFQzVHg1WHdHQ1V3czlFVFJPVTlLWDNOZUg2dXQxRjZoMXUzSUdCZmo3WUNH?=
 =?utf-8?B?SFdNM0xVNEM2ZmwrcEliV3dBTnBNU1pHbzNvcjNBQWFhNnNtVW5iY2p4OUQy?=
 =?utf-8?B?WlNqbGQrQmRNekJWNldZWkJWSkt0NGdnendEWHlPMFJtZjZsa1JZdEFNSUVs?=
 =?utf-8?B?TXA2ZC9oY2xlVGV6Sjk1d2g3bitjMk5LNzAwMGc0azQxM3NlaUovd2NMVGJF?=
 =?utf-8?B?SUJQNis1SkFjcVZYUnlpTUJiQzQzN1pvQW9nT01BakpkUXZpUGpha3hzcFVP?=
 =?utf-8?B?WFBnK1F2Ri9Ka0s5cktTa1NyQk11L2hjMlBDa09XeFdTK05HUGxVRjBvNnRV?=
 =?utf-8?B?SUkzb3pXNEdKZVBHZS9WWEwyT1dlUDYvS1ZwcHVTWVNQTXQ2VDlmWk45clpM?=
 =?utf-8?B?SnhxZWFTTVF2UnVaWUlSL2pRSUlodVd6VmlNdEVCUmJ1dFFUNDNORk81Rkkx?=
 =?utf-8?B?ZTBpNzhHcGY5bEdPZ2F3dTFHc21rWnlZZnNXREROSmpXbUM5bmF4MkN0eUo4?=
 =?utf-8?B?ZG1YaWMydE9EaFhlZWh0ckdqaWltVjdCbjRUcGhMajIzVnpiWXZvTlY0RlF6?=
 =?utf-8?B?SGVHeTM5YWpDWHQ5emsxZEdPR2N4RllaWEE1WmFGM1puV0JaM3NTcTdwL2hX?=
 =?utf-8?B?M3JqRndnQnpWNEJoMVUvRUN1dkhBRzlIV2QxQ3pUMjZJZ0JoWmtWSmJEbCtU?=
 =?utf-8?B?ZHl6aGhmdUtlSm80NzRzSUxqOXc0WHFRc1d2bzd5ZzhCNVJ4ZUlZUG5HOTJO?=
 =?utf-8?B?SEk4SkZMN3hQbTEyeEZ6blcxSUtqSm9WRmYyYVJXS0w0NXdGMUF6dEEyQ0Fp?=
 =?utf-8?B?Si95K0ExUXlGZGhIR3VwdVpteWlSNm56aXZKdmtQT3hEUVIxMnhweGtVUDdI?=
 =?utf-8?B?THVWUGNnK203ZW91N0svYnU5VlUxNEMyQm5nTGZqK3E3b3FMWk9RdDU1VkJv?=
 =?utf-8?Q?/WbXiRbpN5u9OblBOWfpJa9WveEVoLpxgGImj0cVQl+N?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 31cac634-54d0-4eac-f907-08da7eb13fa1
X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3587.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Aug 2022 11:28:17.1205
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: t5w3v60m2R264dzCYE5uiqiYEjXnVjXsOPQzB4rBWF4M4G/cHpK0zrFnoi5Bv0tb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR12MB2403
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Am 15.08.22 um 13:19 schrieb Dmitry Osipenko:
> [SNIP]
>>>> I'll try to dig out the older discussions, thank you for the quick
>>>> reply!
>>> Are you sure it was really discussed in public previously? All I can
>>> find is yours two answers to a similar patches where you're saying that
>>> this it's a wrong solution without in-depth explanation and further
>>> discussions.
>> Yeah, that's my problem as well I can't find that of hand.
>>
>> But yes it certainly was discussed in public.
> If it was only CC'd to dri-devel, then could be that emails didn't pass
> the spam moderation :/

That might be possible.

>>> Maybe it was discussed privately? In this case I will be happy to get
>>> more info from you about the root of the problem so I could start to
>>> look at how to fix it properly. It's not apparent where the problem is
>>> to a TTM newbie like me.
>>>
>> Well this is completely unfixable. See the whole purpose of TTM is to
>> allow tracing where what is mapped of a buffer object.
>>
>> If you circumvent that and increase the page reference yourself than
>> that whole functionality can't work correctly any more.
> Are you suggesting that the problem is that TTM doesn't see the KVM page
> faults/mappings?

Yes, and no. It's one of the issues, but there is more behind that (e.g. 
what happens when TTM switches from pages to local memory for backing a BO).

Another question is why is KVM accessing the page structure in the first 
place? The VMA is mapped with VM_PFNMAP and VM_IO, KVM should never ever 
touch any of those pages.

Regards,
Christian.