xen/arch/x86/acpi/suspend.c | 55 ++-------------- xen/arch/x86/acpi/wakeup_prot.S | 136 ++++++++++++---------------------------- xen/arch/x86/boot/wakeup.S | 2 +- 3 files changed, 46 insertions(+), 147 deletions(-)
Andrew Cooper (6): x86/suspend: Clarify and improve the behaviour of do_suspend_lowlevel() x86/suspend: Don't bother saving %cr3, %ss or flags x86/suspend: Don't save unnecessary GPRs x86/suspend: Restore cr4 later during resume x86/suspend: Expand macros in wakeup_prot.S x86/suspend: Drop save_rest_processor_state() completely xen/arch/x86/acpi/suspend.c | 55 ++-------------- xen/arch/x86/acpi/wakeup_prot.S | 136 ++++++++++++---------------------------- xen/arch/x86/boot/wakeup.S | 2 +- 3 files changed, 46 insertions(+), 147 deletions(-) -- 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
On 13.12.2019 20:04, Andrew Cooper wrote: > Andrew Cooper (6): > x86/suspend: Clarify and improve the behaviour of do_suspend_lowlevel() > x86/suspend: Don't bother saving %cr3, %ss or flags > x86/suspend: Don't save unnecessary GPRs > x86/suspend: Restore cr4 later during resume > x86/suspend: Expand macros in wakeup_prot.S > x86/suspend: Drop save_rest_processor_state() completely > > xen/arch/x86/acpi/suspend.c | 55 ++-------------- > xen/arch/x86/acpi/wakeup_prot.S | 136 ++++++++++++---------------------------- > xen/arch/x86/boot/wakeup.S | 2 +- > 3 files changed, 46 insertions(+), 147 deletions(-) Based on Roger's review Acked-by: Jan Beulich <jbeulich@suse.com> One remark on the combination of patches 2 and 5: The loading of the stack related registers would now seem to be a fair candidate for using LSS (generally to be preferred over MOV-to-SS). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
On 17/12/2019 16:17, Jan Beulich wrote: > On 13.12.2019 20:04, Andrew Cooper wrote: >> Andrew Cooper (6): >> x86/suspend: Clarify and improve the behaviour of do_suspend_lowlevel() >> x86/suspend: Don't bother saving %cr3, %ss or flags >> x86/suspend: Don't save unnecessary GPRs >> x86/suspend: Restore cr4 later during resume >> x86/suspend: Expand macros in wakeup_prot.S >> x86/suspend: Drop save_rest_processor_state() completely >> >> xen/arch/x86/acpi/suspend.c | 55 ++-------------- >> xen/arch/x86/acpi/wakeup_prot.S | 136 ++++++++++++---------------------------- >> xen/arch/x86/boot/wakeup.S | 2 +- >> 3 files changed, 46 insertions(+), 147 deletions(-) > Based on Roger's review > Acked-by: Jan Beulich <jbeulich@suse.com> > > One remark on the combination of patches 2 and 5: The loading of > the stack related registers would now seem to be a fair candidate > for using LSS (generally to be preferred over MOV-to-SS). Well... You've just fixed c/s ffa21ea5303 in the emulator, and it demonstrates why LSS can't be used. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
On 17.12.2019 17:33, Andrew Cooper wrote: > On 17/12/2019 16:17, Jan Beulich wrote: >> On 13.12.2019 20:04, Andrew Cooper wrote: >>> Andrew Cooper (6): >>> x86/suspend: Clarify and improve the behaviour of do_suspend_lowlevel() >>> x86/suspend: Don't bother saving %cr3, %ss or flags >>> x86/suspend: Don't save unnecessary GPRs >>> x86/suspend: Restore cr4 later during resume >>> x86/suspend: Expand macros in wakeup_prot.S >>> x86/suspend: Drop save_rest_processor_state() completely >>> >>> xen/arch/x86/acpi/suspend.c | 55 ++-------------- >>> xen/arch/x86/acpi/wakeup_prot.S | 136 ++++++++++++---------------------------- >>> xen/arch/x86/boot/wakeup.S | 2 +- >>> 3 files changed, 46 insertions(+), 147 deletions(-) >> Based on Roger's review >> Acked-by: Jan Beulich <jbeulich@suse.com> >> >> One remark on the combination of patches 2 and 5: The loading of >> the stack related registers would now seem to be a fair candidate >> for using LSS (generally to be preferred over MOV-to-SS). > > Well... You've just fixed c/s ffa21ea5303 in the emulator, and it > demonstrates why LSS can't be used. Hmm, indeed, how did I forget? (It's really very counter-intuitive for this insn to not be universally usable.) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
On 17/12/2019 16:39, Jan Beulich wrote:
> On 17.12.2019 17:33, Andrew Cooper wrote:
>> On 17/12/2019 16:17, Jan Beulich wrote:
>>> On 13.12.2019 20:04, Andrew Cooper wrote:
>>>> Andrew Cooper (6):
>>>> x86/suspend: Clarify and improve the behaviour of do_suspend_lowlevel()
>>>> x86/suspend: Don't bother saving %cr3, %ss or flags
>>>> x86/suspend: Don't save unnecessary GPRs
>>>> x86/suspend: Restore cr4 later during resume
>>>> x86/suspend: Expand macros in wakeup_prot.S
>>>> x86/suspend: Drop save_rest_processor_state() completely
>>>>
>>>> xen/arch/x86/acpi/suspend.c | 55 ++--------------
>>>> xen/arch/x86/acpi/wakeup_prot.S | 136 ++++++++++++----------------------------
>>>> xen/arch/x86/boot/wakeup.S | 2 +-
>>>> 3 files changed, 46 insertions(+), 147 deletions(-)
>>> Based on Roger's review
>>> Acked-by: Jan Beulich <jbeulich@suse.com>
>>>
>>> One remark on the combination of patches 2 and 5: The loading of
>>> the stack related registers would now seem to be a fair candidate
>>> for using LSS (generally to be preferred over MOV-to-SS).
>> Well... You've just fixed c/s ffa21ea5303 in the emulator, and it
>> demonstrates why LSS can't be used.
> Hmm, indeed, how did I forget? (It's really very counter-intuitive
> for this insn to not be universally usable.)
The differing behaviour between Intel and AMD makes L*S and call gates
totally unusable, even in situations where they might be useful.
In practice, call gates where killed by SYS{CALL,ENTER}/{RET,EXIT} being
4x faster than anything referencing the IDT/GDT, and L*S have had a
complicated history of availability even in the 32bit days.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 18.12.2019 12:39, Andrew Cooper wrote:
> In practice, call gates where killed by SYS{CALL,ENTER}/{RET,EXIT} being
> 4x faster than anything referencing the IDT/GDT, and L*S have had a
> complicated history of availability even in the 32bit days.
I'm curious - what complicated history? They'd been added with the
386, and I don't recall any quirks or issues with them.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
© 2016 - 2024 Red Hat, Inc.