Received-SPF: pass (google.com: domain of linux-kernel+bounces-109420-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <cc3a968d-c581-4784-b69b-b887d3b90a94@intel.com>
Date: Thu, 21 Mar 2024 10:00:24 +1300
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v19 007/130] x86/virt/tdx: Export SEAMCALL functions
Content-Language: en-US
To: Dave Hansen <dave.hansen@intel.com>, "seanjc@google.com"
	<seanjc@google.com>
CC: "Zhang, Tina" <tina.zhang@intel.com>, "Edgecombe, Rick P"
	<rick.p.edgecombe@intel.com>, "Yuan, Hang" <hang.yuan@intel.com>,
	"x86@kernel.org" <x86@kernel.org>, "Chen, Bo2" <chen.bo@intel.com>,
	"sagis@google.com" <sagis@google.com>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "isaku.yamahata@gmail.com"
	<isaku.yamahata@gmail.com>, "Aktas, Erdem" <erdemaktas@google.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, "pbonzini@redhat.com"
	<pbonzini@redhat.com>, "Yamahata, Isaku" <isaku.yamahata@intel.com>
References: <cover.1708933498.git.isaku.yamahata@intel.com>
 <8f64043a6c393c017347bf8954d92b84b58603ec.1708933498.git.isaku.yamahata@intel.com>
 <e6e8f585-b718-4f53-88f6-89832a1e4b9f@intel.com>
 <bd21a37560d4d0695425245658a68fcc2a43f0c0.camel@intel.com>
 <54ae3bbb-34dc-4b10-a14e-2af9e9240ef1@intel.com>
 <ZfR4UHsW_Y1xWFF-@google.com>
 <ea85f773-b5ef-4cf6-b2bd-2c0e7973a090@intel.com>
 <ZfSjvwdJqFJhxjth@google.com>
 <8d79db2af4e0629ad5dea6d8276fc5cda86a890a.camel@intel.com>
 <70d7a20a-72dc-4ded-a35f-684de44eb6e6@intel.com>
From: "Huang, Kai" <kai.huang@intel.com>
In-Reply-To: <70d7a20a-72dc-4ded-a35f-684de44eb6e6@intel.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R2FuSVVCT1o0WnUrQ3h4SklOQ1hzVGZsTUdCTWU3UFM0Uk5JT3FpRWc5YmNW?=
 =?utf-8?B?N2RMZE1DdDNhem8rS013bEJNWDZuRUU4Z3prQnBtb3RlWkJXNzhIMjJnVFZt?=
 =?utf-8?B?bmNidmN5VkFxY2UvckdJWCsrWTEvbXRaL1E5SE5NK2tnUytSOHZaTVpZRUFx?=
 =?utf-8?B?ek9LTEtyZHY2ZkZKTFBGbmZvN25ld1h4cWRHVFNadEFiSGlGSDJNZWhpK3l3?=
 =?utf-8?B?NWhDWjMxU2t2c01XTnZ2Wkx6UGpQVmNvWUNDcGVCdWI5NEREL01qdkc1V1Bu?=
 =?utf-8?B?QmhkeDAxalpqQXpXNWYzNWFwUXBpMXJ6QkxsUkl1dGt3bmtCS3lxNFUvY3lw?=
 =?utf-8?B?RWIra2ZrNmJTSVRvYjdYb0NZeGo4a1ptNHpabng4b01HMDVzNXc1N0ZaZVpE?=
 =?utf-8?B?aU04bFBSZ05XNHl2cmFLU0E0aDc0Z0I2Yk1qTGo4Y01ZZVZsN3JyZFZ2V3dR?=
 =?utf-8?B?cmd0U0NBMitKUGJlTldyclpqaDRsVGVXT1hYc3oxOVVRQUUzOGFHNEF5VkhC?=
 =?utf-8?B?Y0NFb0lzcVNKTDFFUjdFUHhxM0xVdXNqU1dvaEM5Z0lJQUU2MnhHbWxKUzd3?=
 =?utf-8?B?bVVySFNBdjVTSWtTM1V5bE5RbmZLQnBySnFnc1hBQ1VsWjhxdENFNnFyNzlJ?=
 =?utf-8?B?Qms2STA1N24rT0RqNTlsWVhySmExcGZUYkp2bXlGem1raFJWOE1BOXFINVlD?=
 =?utf-8?B?TUk3R1NxamoyczBwZkNDS2t4VDgzdHZIMjF2ajdoay9OY1NoeDA4V3NiZUxY?=
 =?utf-8?B?TmZPdldhOHNNT1RwSjI5Tks0Q0FwYWJrWU5EZUxNV0UvaURkakRka2lKajd1?=
 =?utf-8?B?ajU3WWRmaWJuNEw4cTd6TkVhOElwVFQ3L3ZPdEsvRXVXMHRBZ3pKVkp1Um5t?=
 =?utf-8?B?Slg3ckFUR2FCajQvVUlxY0g2Qkl1MU9aUWI5UGdUeXpBNXZmQ0N2aHVVcjly?=
 =?utf-8?B?RFJHbTFUT1Z4dThXclJPeUkwOG42ZnN3cld2WXZGZTlEWUI3V1dMeTd3Z29x?=
 =?utf-8?B?RThZdmQzTEtUdFl4U045N2FFdWxhbU0velNwK1BSY0hXdEh0NUpISFdnb3JP?=
 =?utf-8?B?RHhqRDk2US9Fd3pCYU5na2tTeisrWEZCKzVDZk1rR1lyNEYxaGNRVVk1aGtq?=
 =?utf-8?B?RHF6YlkzSy9WV0hFMEVCdm50NEtiaHJIQy9CdHVjKzRiaDU0QlFzWnM4SnFt?=
 =?utf-8?B?MVFUdUVJTDhxOGk1QnpBblpRU3FoZ0FOVU5sSHJmeFBBcWdiazlYSXUxM1NM?=
 =?utf-8?B?UnV1bktpV2ovb3QzTzI2c212TE1nNnE1SVJTcVRVNGYxZzRlNHNCY202blpu?=
 =?utf-8?B?OGNuNVVYNkZwbHFwOVRYY2JIdmw3VnljMW1NVVJDT2FqbWIvRUlMVFlzb0pR?=
 =?utf-8?B?MkJqZmZKREZUU0hZN1lwNjBNaEdnSWJObWxra25RcTEvK1Avbms2NDVEeVFD?=
 =?utf-8?B?SGtObjRyZ00yR2hjMUpVWC9aRmUvZnNMU2xnckp1QnA4WExZMWhUZnZvS3Rq?=
 =?utf-8?B?TjZBc3RNMU5LOU02LzFJWjA1TVBuckJqaDRhTlBZWTd5SzNWOXI5LytPeVZS?=
 =?utf-8?B?SWl3WFd3R2ZoUXNCc3Z2dnB4R2gxNklwTDI5WHFwazFYaVVrcXdsZnJEWEdy?=
 =?utf-8?B?UGJaOXF1aGNSTnhIbnFUU1lVcU5OdkEzZ3E4ZmNFUEFwNjJnOUhlOHlJdm5N?=
 =?utf-8?B?UU1Xb0xQUHVOUCtoemUwQXBZRGZNbHkyd2RVSVJpVk80a214RkYwUTdOelpw?=
 =?utf-8?B?aktqRkFWbUlCQU5YZlY0S1k2NWs4QmZWOTF0Z1dRQU05TS9FaXRkdnhCS3Y0?=
 =?utf-8?B?V3kxMC8xaEFGZlZHQlRPQlp0OW5uVlNySjBFMU5SL3gwcTFWbFRuSWpnYTRC?=
 =?utf-8?B?bVI5OHNvVnJNNHlSNDhhdkdJaG5FZTMvYUUyOVVKMGtCMU9IaCsyZDdTL0wr?=
 =?utf-8?B?TlIrOHhSL0w1cC9ZU3JLOXB3c3hmRFlKSENpVU00NnBhR2c4MFBub3pkQ0tH?=
 =?utf-8?B?KzBvY3VDQ0VCWnltU014UHQ1Vy9saVB1cGsrNUxkSHpuQ2JNbU1BWC9wK0p3?=
 =?utf-8?B?aGFhQmVOTTNNbW1lOUhCT0tPNnBvaVZLaVNVemZONGxuc0MzOXdndHIxaWhP?=
 =?utf-8?Q?fABk+3gJYxdonPG8e3NInux41?=
X-MS-Exchange-CrossTenant-Network-Message-Id: afac53b2-6428-481e-d1f1-08dc4920cc3b
X-MS-Exchange-CrossTenant-AuthSource: BL1PR11MB5978.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 21:00:39.5518
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ChwefPmXNg3iiM38G6TT/pEqefnbrPVd14+JrnjCvOhp5Z6sZ27fsPxecVPGFTam9nZRDkGT2BrqNG7PulaNUA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB7094
X-OriginatorOrg: intel.com


On 21/03/2024 4:07 am, Dave Hansen wrote:
> On 3/20/24 05:09, Huang, Kai wrote:
>> I can try to do if you guys believe this should be done, and should be done
>> earlier than later, but I am not sure _ANY_ optimization around SEAMCALL will
>> have meaningful performance improvement.
> 
> I don't think Sean had performance concerns.
> 
> I think he was having a justifiably violent reaction to how much more
> complicated the generated code is to do a SEAMCALL versus a good ol' KVM
> hypercall.

Ah, I automatically linked "generating better code" to "in order to have 
better performance".  My bad.

> 
> "Complicated" in this case means lots more instructions and control
> flow.  That's slower, sure, but the main impact is that when you go to
> debug it, it's *MUCH* harder to debug the SEAMCALL entry assembly than a
> KVM hypercall.

[...]

> 
> My takeaway from this, though, is that we are relying on the compiler
> for a *LOT*.  There are also so many levels in the helpers that it's
> hard to avoid silly things like two _separate_ retry loops.
> 
> We should probably be looking at the generated code a _bit_ more often
> than never, and it's OK to tinker a _bit_ to make things out-of-line or
> make sure that the compiler optimizes everything that we think that it
> should.

Yeah, agreed.

> 
> Also remember that there are very fun tools out there that can make this
> much easier than recompiling the kernel a billion times:
> 
> 	https://godbolt.org/z/8ooE4d465

Ah, this is useful.  Thanks for sharing :-)