[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v5 3/6] x86: re-work memcpy()
Le 06/06/2025 à 11:13, Jan Beulich a écrit : > On 05.06.2025 19:06, Teddy Astie wrote: >> Le 05/06/2025 à 12:27, Jan Beulich a écrit : >>> Move the function to its own assembly file. Having it in C just for the >>> entire body to be an asm() isn't really helpful. Then have two flavors: >>> A "basic" version using qword steps for the bulk of the operation, and an >>> ERMS version for modern hardware, to be substituted in via alternatives >>> patching. >>> >>> Alternatives patching, however, requires an extra precaution: It uses >>> memcpy() itself, and hence the function may patch itself. Luckily the >>> patched-in code only replaces the prolog of the original function. Make >>> sure this remains this way. >> >> We can probably workaround that by using a separate memcpy for >> alternatives patching. So it wouldn't end up patching itself. > > We could, yes, but imo we better wouldn't. > As Andrew pointed out that it's not that simple to use a separate memcpy. So should probably keep the current approach. >> Aside that: >> Reviewed-by: Teddy Astie <teddy.astie@xxxxxxxxxx> > > Please clarify whether this applies without that suggestion of yours taken > care of. > Yes. > Jan Teddy Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |