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

Re: [PATCH] SVM: avoid VMSAVE in ctxt-switch-to

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 19 Oct 2020 15:30:49 +0100
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 19 Oct 2020 14:31:10 +0000
  • Ironport-sdr: 2NW4VCpKbbpQTiUYVJwqnjH7RxwYcekGibTeUbWeJV4InFtEtHA+RLaPu/e+N+TzkxVnnc3NdC Cji8B/eeCxt9dbcLPkVNYcwJLU07QcC3Y9SHqzXHqtyr76GsmC5NtY0/5ud4aE9hiUqFfPT1mg FoRS6YgRUQv4JrDnIh6hCf+esNiSWjMr2mJJD2Q1HGgrqNHEmpv9htfADJqxq6QruQuCREuois 3+SI0daBAOW4IfMBc87D0X3/luU6fDBNN25H/BIbfnoUe66+8SHwhOcsiTkp6GKJjLtww1y7IQ /7A=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 19/10/2020 15:21, Jan Beulich wrote:
> On 19.10.2020 16:10, Andrew Cooper wrote:
>> On 19/10/2020 14:40, Jan Beulich wrote:
>>> Of the state saved by the insn and reloaded by the corresponding VMLOAD
>>> - TR, syscall, and sysenter state are invariant while having Xen's state
>>>   loaded,
>>> - FS, GS, and LDTR are not used by Xen and get suitably set in PV
>>>   context switch code.
>> I think it would be helpful to state that Xen's state is suitably cached
>> in _svm_cpu_up(), as this does now introduce an ordering dependency
>> during boot.
> I've added a sentence.
>> Is it possibly worth putting an assert checking the TR selector?  That
>> ought to be good enough to catch stray init reordering problems.
> How would checking just the TR selector help? If other pieces of TR
> or syscall/sysenter were out of sync, we'd be hosed, too.

They're far less likely to move relative to tr, than everything relative
to hvm_up().

> I'm also not sure what exactly you mean to do for such an assertion:
> Merely check the host VMCB field against TSS_SELECTOR, or do an
> actual STR to be closer to what the VMSAVE actually did?


The problem with the other state is that it compiletime/runtime
dependent, and we don't want to be opencoding the logic a second time.




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