[PATCH 0/7] x86: memcpy() / memset() (non-)ERMS flavors plus fallout

Jan Beulich posted 7 patches 2 weeks, 6 days ago
Test gitlab-ci passed
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/6d6da76c-ccc8-afa2-bd06-5ae132c354f2@suse.com

[PATCH 0/7] x86: memcpy() / memset() (non-)ERMS flavors plus fallout

Posted by Jan Beulich 2 weeks, 6 days ago
While the performance varies quite a bit on older (pre-ERMS) and
newer (ERMS) hardware, so far we've been going with just a single
flavor of these two functions, and oddly enough with ones not
consistent with one another. Using plain memcpy() / memset() on
MMIO (video frame buffer) is generally okay, but the ERMS variant
of memcpy() turned out to regress (boot) performance in a way
easily visible to the human eye. Hence as a prerequisite step
this series switches the frame buffer (and VGA) mapping to be
write-combining independent of firmware arrangements (of MTRRs
in particular).

1: x86: correct comment about alternatives ordering
2: x86: introduce ioremap_wc()
3: x86: re-work memset()
4: x86: re-work memcpy()
5: video/vesa: unmap frame buffer when relinquishing console
6: video/vesa: drop "vesa-mtrr" command line option
7: video/vesa: adjust (not just) command line option handling

Side note: While strictly speaking the xen/drivers/video/ changes
fall under REST maintainership, with that code getting built for
x86 only I'm restricting Cc-s to x86 maintainers.