[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/8] x86/svm: VMEntry/Exit logic for MSR_SPEC_CTRL


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Date: Thu, 27 Jan 2022 21:55:54 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3dro7bpOrzYdjVfXa1cR+Dfph1OtQWZIml24Wy7KIdE=; b=jVJm39QoOdGQja9j3hXc2pgbvvDz/p+Jd9wQZY2ygOww0H9/7z8O8B3auGddn1yMtXUsSjDqTbBllRFjqZcfpozjKRbBCwa3TYFLS1oClMoQHxrHk3XEAnavUeLYQYkHrs77xSbi5EZTHMnyvjUBj4ck6ZbTbP/tZNEFah/Qr/PYZOvTFuX9yPVr/8BPg4hEYPYb552MxFQkfqbB3uYc4J1p3RK9PrU0qahtGeL294Jn6DU2uX6jONOCCE8ZWe/MZWMu/944E9hXkTqnbUaKd9yWIijMTmC01HI1rPQdmAM9s4V8u+FhLsL4LY5gj58GQrP5WnVTQwo162Al5K+cbg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hctyBWSd5sfLXvV/DZLL43gjaf52J0YhU5L3EpuGtggfmMStpmimLryzZJ0BgMHhYljQCHCaP8x8yzPHW3g/SRFHLHx5itx2ARjUeux0xkIGiZTjVXWIewnDNg0bJyH5w9Wemak+pFtjrkhOvf5rFzsgHFcUtZXjCrgzqy50FihACwmA5dten7j0KmZ/SXJwg9p+6M7HvRpx6N6ChcTBLVt7kbWQAiMhl1AE45Pv9hDqWbj4yf/HW2IW/1P4HejTD199ODSfKPkl/ShsdKa6yXA2RkyzrpHcRUVLjldctdxHj/5benxMt26JjphbTKT9Py3642xd7HlZLopUsCV84g==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 27 Jan 2022 21:56:39 +0000
  • Ironport-data: A9a23:KZSmH6rEX/gCXUUbfhAUlqLyMYVeBmL1YhIvgKrLsJaIsI4StFCzt garIBnXa6mNZjT8c9okO4rk9E1SsJDWndM2SARo+C8zEy9A8JuZCYyVIHmrMnLJJKUvbq7GA +byyDXkBJppJpMJjk71atANlZT4vE2xbuKU5NTsY0idfic5Dndx4f5fs7Rh2NQw2ILmW1nlV e7a+KUzBnf0g1aYDUpMg06zgEsHUCPa4W5wUvQWPJinjXeG/5UnJMt3yZKZdhMUdrJ8DO+iL 9sv+Znilo/vE7XBPfv++lrzWhVirrc/pmFigFIOM0SpqkAqSiDfTs/XnRfTAKtao2zhojx/9 DlCnZ6OFjcuB6n0o9YYQhh+Fn9VO7wfoIaSdBBTseTLp6HHW37lwvEoB0AqJ4wIvO1wBAmi9 9RBdmpLNErawbvrnvTrEYGAhex6RCXvFKoZtmtt0nfyCvE+TIqYa67L+cVZzHE7gcUm8fP2O ZBIMmcwM0+ojxtnPmkbAs8Pw/mSuUbiLBgbiFLI/I4oyj2GpOB2+Oe0a4eEEjCQfu1Fk0Ddq m/Y8mDRBhABKMfZ2TeD6mirhOLEgWX8Qo16PKK83u5nhhuU3GN7IB8cWEa/oPK5olWjQN8ZI EsRkhfCtoBrqhbtFIOkGUTl/jjU5XbwRua8DcU41l69zZPQ2z2rA3kFaDsfQ9o37ZcPEGlCO kCyo/vlAjlmsbuwQH2b96uJoT7aBRX5PVPudgdfE1JbvoCLTJUby0uWE409SPLdYsjdRGmoq w1muhTSkFn6YSQj86ygtW7KjDu3znQiZl5kv16HNo5JA+4QWWJEW2BKwQWDhRqjBNzAJrVkg JTis5LDhAzpJcrV/BFhuM1XQNmUCw+taVUwe2JHEZg77CiK8HW+Z41W6zwWDB43bp1eImeyP hKL5FI5CHpv0J2CN/Efj2WZUJxC8EQdPY69CqC8giRmPPCdizNrDAkxPBXNjggBYWAnkL0lO IfzTCpfJS1yNEiT9xLvH711+eZynkgWnDqPLbimkUjP+efANRa9FOdUWHPTP7tRxP7V/23oH yN3apHiJ+N3CrOuO0E6MOc7cDg3EJTMLcmm8pMMLr/afFMO9aNII6a5/I7NsrdNxsx9vuzJ4 mu8Sglfzl/+jmfAMgKEdjZob7aHYHq1hSxT0fUEMQn61n49T5yo6atDJZI7caN+rL5ozOJuT ulDcMKFW6wdRjPC8jUbTJ/8sI09K0j72VPQZ3KoMGolYpptZw3V4du4LAHhwzYDU3isvswkr rz+ig6CGcgfRx5vBdr9Ye60yw/jpmAUne9/BhOaItRadEj23pJtLij90q0+L80WcE2RzTqGz QeGRxwfoLCV8YMy9dDIg4GCrpuoTLQiThYLQTGD4O/vZyfA/2elzYtRa8qyfGjQBDHu5aGvR eRJ1PWgYvcJq0lH7thnGLFxwKNgu9a2/+1Gzh5pFWngZkiwDu8yOWGP2MRCu/EfxrJdvgfqC EuD9sMDZOeMMcLhVlUQOBAkfqKI0vRNwmve6vE8IUPb4i5r/eXYDRUObkfU0CENfqFoNI4Fw Ps6vJ9E4gOyvRMmL9Kag30G7G+LNHEBD/0qu5xy7FUHUeb3JoWuuaDhNxI=
  • Ironport-hdrordr: A9a23:mcBfNal05SwCZSiymX/JBiD1EaXpDfOIimdD5ihNYBxZY6Wkfp +V88jzhCWZtN9OYhwdcIi7SdS9qXO1z+8R3WGIVY3SEjUOy1HYUL2KirGSggEIeheOudK1sJ 0PT0EQMqyIMbEXt7eY3OD8Kadb/DDlytHpuQ699QYUcegCUcgJhG0ZajpzUHcGPzWubaBJTq Z0jfA3wwZIDE5nCPhTcUN1ONQryee79q7OUFojPVoK+QOOhTSn5PrRCB6DxCoTVDtJ3PML7X XFuxaR3NThj9iLjjvnk0PD5ZVfn9XsjvFZAtaXt8QTIjLwzi61eYVaXaGYtjxdmpDs1L9qqq iIn/4TBbU115rjRBDynfIr4Xi47N8a0Q6n9bZfuwq6nSW2fkNgNyMLv/MnTvKQ0TtfgDg76t MX44vRjesmMfuL9h6NluTgRlVkkFG5rmEllvNWh3tDUZEGYLsUtoAH+lhJea1wVh4SxbpXWN WGNvusr8q+sGnqG0zxry1q2pihT34zFhCJTgwLvdGUySFfmDR8w1EDzMISk38c/NZlIqM0q9 jsI+BtjvVDX8UWZaVyCKMIRta2EHXERVbJPHiJKVrqGakbMzbGqoLx4r8y+Oa2EaZ4gacaid DEShdVpGQyc0XhBYmH24BK6AnERCGnUTHk2qhlltFEU33HNczW2AG4OSITevqb0oIi65fgKo WO0bptcoreEVc=
  • Ironport-sdr: ft+AMviMAtE1rx7KPEq1kNOzYc5hUZwdAHxCnt0I6SPIXY6Jyh01jDbxmq3mjKRIsP8Rp3mpRs o12oZ3aPy6Th1NEFSm1pZyanRP5X2E2NI7qKJHt7tyrU5TA2e/mnY0WtdKzxhSudPpie3PCvIU vzIvWOku4BkzeHwtNmY6YhnaosjAyHh4GscqjepQr1j7xsvdPSQcrM846tRdQ7ZEML+lZO0Y8o HEFR7l5FpITiBdgBaNfi683EZVn2xkPiL626AWQ2Qnfs8Fq2G59L3Wu2cJFgpLh6w7KSLcXVIz /6HGCg6kO5qcdnGNlraTFWlj
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHYEpEQO22I/y1Di0S4u/YrCMvx5qx1hJwAgAA5Y4CAALsGAIAA8yeA
  • Thread-topic: [PATCH 3/8] x86/svm: VMEntry/Exit logic for MSR_SPEC_CTRL

On 27/01/2022 07:25, Jan Beulich wrote:
> On 26.01.2022 21:16, Andrew Cooper wrote:
>> On 26/01/2022 16:50, Jan Beulich wrote:
>>> On 26.01.2022 09:44, Andrew Cooper wrote:
>>>> 1) It would be slightly more efficient to pass curr and cpu_info into
>>>>    vm{entry,exit}_spec_ctrl(), but setup of such state can't be in the
>>>>    ALTERNATIVE block because then the call displacement won't get fixed up.
>>>>    All the additional accesses are hot off the stack, so almost certainly
>>>>    negligible compared to the WRMSR.
>>> What's wrong with using two instances of ALTERNATIVE, one to setup the
>>> call arguments and the 2nd for just the CALL?
>> Hmm
>>
>> diff --git a/xen/arch/x86/hvm/svm/entry.S b/xen/arch/x86/hvm/svm/entry.S
>> index c718328ac4cf..1d4be7e97ae2 100644
>> --- a/xen/arch/x86/hvm/svm/entry.S
>> +++ b/xen/arch/x86/hvm/svm/entry.S
>> @@ -59,6 +59,7 @@ __UNLIKELY_END(nsvm_hap)
>>  
>>          /* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */
>>          /* SPEC_CTRL_EXIT_TO_SVM       Req:                          
>> Clob: C   */
>> +        ALTERNATIVE "", __stringify(mov %rbx, %rdi; mov %rsp, %rsi),
>> X86_FEATURE_SC_MSR_HVM
>>          ALTERNATIVE "", __stringify(call vmentry_spec_ctrl),
>> X86_FEATURE_SC_MSR_HVM
>>  
>>          pop  %r15
>>
>> is somewhat of a long line, but isn't too terrible.
>>
>> I'm tempted to switch back to using STR() seeing as we have both and it
>> is much more concise.
> No objections. In fact I think when I introduced stringify.h over 10 years
> back, I didn't realize we already had STR(). Quite certainly first and
> foremost because of its bogus placement in xen/config.h (same would go for
> at least IS_ALIGNED() as well as KB() and friends).
>
> I wouldn't even mind phasing out stringify.h again. Or maybe we want to
> move STR() there ...

Now that we've given up using freestanding headers anywhere, there's a
xen/stddef.h shaped hole.

Things like NULL should move across, but it would also be the
appropriate place for ARRAY_SIZE() and pretty much everything else we
expect to be ubiquitous.  Linux includes things like offsetof().

~Andrew

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.