[PATCH 00/16] x86: assorted (mostly) shadow mode adjustments

Jan Beulich posted 16 patches 1 year, 1 month ago
Failed in applying to current master (apply log)
[PATCH 00/16] x86: assorted (mostly) shadow mode adjustments
Posted by Jan Beulich 1 year, 1 month ago
This is kind of fallout from XSA-427 investigations, partly related to
there having been a more intrusive first approach. This is also the
reason why one of the patch has R-b already - that was a prereq for
the original approach.

Most patches aren't really dependent upon one another, so can probably
go in independently (as they get acked).

01: shadow: fix and improve sh_page_has_multiple_shadows()
02: shadow: fold/rename sh_unhook_*_mappings()
03: shadow: drop redundant present bit checks from SHADOW_FOREACH_L<N>E() "bodys"
04: shadow: replace memcmp() in sh_resync_l1()
05: shadow: reduce explicit log-dirty recording for HVM
06: shadow: purge {write,cmpxchg}_guest_entry() hooks
07: shadow: call sh_update_cr3() directly sh_page_fault()
08: shadow: use lighter weight mode checks
09: shadow: OOS mode is HVM-only
10: shadow: move OOS functions to their own file
11: shadow: drop is_hvm_...() where easily possible
12: shadow: make monitor table create/destroy more consistent
13: shadow: vCPU-s never have "no mode"
14: shadow: "monitor table" is a HVM-only concept
15: shadow: adjust monitor table prealloc amount
16: PV: conditionalize arch_set_info_guest()'s call to update_cr3()

Jan
Re: [PATCH 00/16] x86: assorted (mostly) shadow mode adjustments
Posted by Andrew Cooper 1 year, 1 month ago
On 22/03/2023 9:28 am, Jan Beulich wrote:
> This is kind of fallout from XSA-427 investigations, partly related to
> there having been a more intrusive first approach. This is also the
> reason why one of the patch has R-b already - that was a prereq for
> the original approach.
>
> Most patches aren't really dependent upon one another, so can probably
> go in independently (as they get acked).
>
> 01: shadow: fix and improve sh_page_has_multiple_shadows()
> 02: shadow: fold/rename sh_unhook_*_mappings()
> 03: shadow: drop redundant present bit checks from SHADOW_FOREACH_L<N>E() "bodys"
> 04: shadow: replace memcmp() in sh_resync_l1()
> 05: shadow: reduce explicit log-dirty recording for HVM
> 06: shadow: purge {write,cmpxchg}_guest_entry() hooks
> 07: shadow: call sh_update_cr3() directly sh_page_fault()
> 08: shadow: use lighter weight mode checks
> 09: shadow: OOS mode is HVM-only
> 10: shadow: move OOS functions to their own file
> 11: shadow: drop is_hvm_...() where easily possible
> 12: shadow: make monitor table create/destroy more consistent
> 13: shadow: vCPU-s never have "no mode"
> 14: shadow: "monitor table" is a HVM-only concept
> 15: shadow: adjust monitor table prealloc amount
> 16: PV: conditionalize arch_set_info_guest()'s call to update_cr3()

Out of interest, I looked at the net delta from this, and it's quite
interesting.

For data:
add/remove: 0/0 grow/shrink: 1/7 up/down: 8/-112 (-104)
__func__                                    2986    2994      +8
sh_paging_mode__guest_4                       96      80     -16
...

which is nice all around.  (Shame that __func__ is being merged
everywhere but oh well.)

For code, two notable exerts:
add/remove: 6/5 grow/shrink: 5/39 up/down: 1549/-3499 (-1950)
Function                                     old     new   delta
mod_l1_entry                                2120    2008    -112
do_mmu_update                               6548    6209    -339

I can't see any patch which obviously makes that change in one go, so I
can only assume it's combination of various small things.

~Andrew