[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





 


Rackspace

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