[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 16:22:55 +0100
  • Authentication-results: esa6.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 15:23:09 +0000
  • Ironport-sdr: rW5d9cAXVkVUmWSfYS9Q90kGhpwTbSh46fca+7PQKdiRboF5luMIGifyTUo2QhVVwhKOBoD5RZ qLiVNoKZJ2bdbFnBTlvBY0GzZssHEaCyXum/5xdHYxPf12hdbVHcFtXfL6TOt7nbpPBa3pje2N nMrGu5o2IyJEY4rKuaNIfTqdiTMg6aCDkaXb0HW96zqiRbISlGIoPqJ+AQertp+pridls5+n3F OrRyiekNyMayOKcE2xUo9K73gknnlzL4/aqIGL9K5b/3jZN7ZMl7gKmm6cBnEupHcr7X0cGYMS Mpc=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 19/10/2020 16:02, Jan Beulich wrote:
> On 19.10.2020 16:30, Andrew Cooper wrote:
>> 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?
>> ASSERT(str() == TSS_SELECTOR);
> Oh, that's odd. How would this help with the VMCB?

It wont.

We're not checking the behaviour of the VMSAVE instruction.  We just
want to sanity check that %tr is already configured.

This version is far more simple than checking VMCB.trsel, which will
require a map_domain_page().

~Andrew



 


Rackspace

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