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: <73e5ed8d-0d25-7d44-8fa2-e1d61b1f5a04@amd.com>
Date:   Mon, 15 Aug 2022 15:53:41 +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>
 <8f749cd0-9a04-7c72-6a4f-a42d501e1489@amd.com>
 <5340d876-62b8-8a64-aa6d-7736c2c8710f@collabora.com>
 <594f1013-b925-3c75-be61-2d649f5ca54e@amd.com>
 <6893d5e9-4b60-0efb-2a87-698b1bcda63e@collabora.com>
From:   =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
In-Reply-To: <6893d5e9-4b60-0efb-2a87-698b1bcda63e@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?NFpsNE40YWhJZVBNdFkyLzdPaTdVd2s3aTlvZHk2NkUySStiWEVqTWdidktU?=
 =?utf-8?B?T2dYbTRDWDFJay9FaWN6aWQ4RW9BM0hiM3NWMXF3RE81WWxlT1RXRGdxM29Q?=
 =?utf-8?B?RTJncXM3Tnh0SGNZQUxzaUx6a0Nlc0t5dnNDUjdML2RJbGxVVzNaaUpBdG5w?=
 =?utf-8?B?aGxnLzZHZXdTNkNLY1ExdUdUd0d6cTdMTWl3SFp0b0lRYitQekZvY2l0bnU3?=
 =?utf-8?B?RlBOWFFONndnMnZLMmFTUnV3VTh5YkJZeVk2aTB6T1Vab3EvSm13YU90dEpB?=
 =?utf-8?B?RGZWeUx3VGN0SHZLeEV4dzhxa3FvUElGVE9naGJDMU9pQ09QNlJpdlp6Uy9u?=
 =?utf-8?B?MTRZQlVKZDg4U3h2SytkM0FHYU92SUszdG9Nd2Z5Zm00a2dDZHN6RXZQdnJx?=
 =?utf-8?B?Q2ZkeWFaa2JwOTFFQk02NGpZcnNETFVETzc5d1F3NHQwb2RoVTRhY1Y5NlNS?=
 =?utf-8?B?NkRjaHpSMUJyYUJkaVcrK0Uza0lYcTRjd1c1YUdtMDRCcTFXZ0xqSERVaDRM?=
 =?utf-8?B?dzkzRGtkVE5HVmU5MTVzcUR2VGZPd0o3QTFkZVZhTWZWS21zU0JYcUNrOUJn?=
 =?utf-8?B?MTN5eGZiK0N1U09WNk1oU281YzV5VFpwc0NpbmVzQUNyWjZoQ0NLaDdPVzRO?=
 =?utf-8?B?dW5kaEpNVUpGR1JKVFR0cjBBUy9mdlJYTmVtTGdSdjVNQ01iYTZFbi9nakNT?=
 =?utf-8?B?N0MxUDBoODNLdmplMitab204aUpSaGRRd2tsQ1RIL0FYUjFseVUxY0Yxall2?=
 =?utf-8?B?djBLY2NDSlRKNzBIR0x2eFU3SWZVSC85UERWemVGbzdZOG8ySmZvaVB3ODcz?=
 =?utf-8?B?R0FDV0NaSXlXcGlTbU4xNWhqYWk5RThzU2Q3dURNUE1vK3ZmYmdHR2l1UTg1?=
 =?utf-8?B?VWRiNFdLSnl5YzU3cTJFWlFnc3I3a1RMNHR5a2JGQnEvU1FvM0pPQzZsbVFs?=
 =?utf-8?B?ckpNTGlMejFPTjNBU1Zhbmx3UXI0QzhCSDJlSStXMm9XMy9sOGJhVGZFVFht?=
 =?utf-8?B?eHhocDlja1BtSnMvdUpFSnRISkdYWm5abDdGdlF0eFdDU2dDaXA3U1Z1dERk?=
 =?utf-8?B?djBSWGdSTFk5V0dnZ3pBMFNjOFExZU1wOVByV3p6cThUU3kyWWdpZkpUc0ZN?=
 =?utf-8?B?QVU1ZjlxL1JsVzl3UnZMb085UDNGVmVzQnFtY1o2M1poMzl2TWlRZmdnZW94?=
 =?utf-8?B?UzNlTXJlVUI1enpqRE5ob0VkdjNTbjYycWV5V0tWaVBWdHY5K21BRzh3SnBB?=
 =?utf-8?B?ZExpQnVpcUU0SUZJb1dxRDM3T2xGM05TRHFEb01JNW83bjBQWEJTanJ4SnpY?=
 =?utf-8?B?cEs2QmFQT3FySXUxZ1A4Q0lkbHVuYjUvUldGcjdPZXNVdFhrRWdhSkpJYUU3?=
 =?utf-8?B?YjRLdWdyM0g0K0E3bWJZdGdYQ2YraHZVeEk2VVY2MG5ZVktsUm92clh1QS85?=
 =?utf-8?B?eWZNeTZPaGMxUnByK1VRSlZYUC8wTWtqM0hnVmJWVDlYSlNHV3Y0NUkrM1RP?=
 =?utf-8?B?Rmh6NjdvRm9hb1F4ZVRQSEZqYmpDNjJIQzV1cDlvWFovWXlubUVSTzVnNTl3?=
 =?utf-8?B?NXJxRzVRSjhPRlZvU1poSWVxaFEzY0Zad2UvWVFFL2orRzZFYjhWbXE0YSt6?=
 =?utf-8?B?bHNnYjVzR1lmOHZpc0VjR1JiOVIzR2NCTG1nSUFDTUsrQnpPRjNLejlDSjJJ?=
 =?utf-8?B?ekNtZTNKeCs4clJpTDBXZFc3eXQyUFNhdnBTTGloRFJFbDZFRnVqNFJLY3lD?=
 =?utf-8?B?cFFGejY3UHd6Qnk3UkFMdktHOGV3OWl0TkR4KzlzUktoN1N3MHBhNUVsdlYv?=
 =?utf-8?B?b0xTdGp5aUFoZ25VTFAyc09hQXJ0UGlMOFlmTkp6RVN5eXY5Zm80RWJJY3Vo?=
 =?utf-8?B?NlRzdWVYSWE0OGhvOWNXcXZZWW1iYnBKVWV3aFFZbGEvZHZPTmZBRHJ2TTgy?=
 =?utf-8?B?dHloWU85YnkvOWQ0WlZwMys1NGd1MlBVTnVObUhZdWM1R0pQQkwyWlBOUG9W?=
 =?utf-8?B?ZVFMM3JKYkpFeW9JMk5iMWgyYUZocTlaNkdpUDRCbGlHdHljTEpEQmxVU3Yx?=
 =?utf-8?B?RU50UFliOVJqb3RIdUJrL0dSdUp4bC9zTDhoZnVxYmRtZ1pkb3VCNjJHK1d1?=
 =?utf-8?B?RzNJSVUzTXc2OUZabW80UzhlZFVNUFRPZldDSnlVN2syc2UzdGZCaU1VVjZI?=
 =?utf-8?Q?6t/nGmtbY4bkEn9T0kpFHINONfsE7k412wlIw8IYRTsy?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d861bd50-a980-4e14-15f6-08da7ec59368
X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3587.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Aug 2022 13:53:47.5731
 (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: /XzAm64Dg9HjXAj/QeFhUqfEJowh4cxBrE3oAAxtr2naYN7pjStEQE9PASrgdt++
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3344
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 15:45 schrieb Dmitry Osipenko:
> [SNIP]
>> Well that comment sounds like KVM is doing the right thing, so I'm
>> wondering what exactly is going on here.
> KVM actually doesn't hold the page reference, it takes the temporal
> reference during page fault and then drops the reference once page is
> mapped, IIUC. Is it still illegal for TTM? Or there is a possibility for
> a race condition here?
>

Well the question is why does KVM grab the page reference in the first 
place?

If that is to prevent the mapping from changing then yes that's illegal 
and won't work. It can always happen that you grab the address, solve 
the fault and then immediately fault again because the address you just 
grabbed is invalidated.

If it's for some other reason than we should probably investigate if we 
shouldn't stop doing this.

Regards,
Christian.