On Thu, 2019-05-02 at 10:23 +0100, Andrew Cooper wrote:
> ...this reasoning is bogus. We're either accessing the data itself, or
> the memcpy function, but there is no possible way to programatically
> avoid "wrong" access into the trampoline, because we're still accessing it.
Just to be clear,
>>> On 02.05.19 at 11:23, wrote:
> On 02/05/2019 09:14, Jan Beulich wrote:
> On 01.05.19 at 13:17, wrote:
>>> We appear to have implemented a memcpy() in the low-memory trampoline
>>> which we then call into from __start_xen(), for no adequately defined
>>> reason.
>> May I suggest that in
> On 02/05/2019 09:14, Jan Beulich wrote:
> On 01.05.19 at 13:17, wrote:
>>> We appear to have implemented a memcpy() in the low-memory trampoline
>>> which we then call into from __start_xen(), for no adequately defined
>>> reason.
>> May I suggest that in cases like this you look at the
On 02/05/2019 09:14, Jan Beulich wrote:
On 01.05.19 at 13:17, wrote:
>> We appear to have implemented a memcpy() in the low-memory trampoline
>> which we then call into from __start_xen(), for no adequately defined
>> reason.
> May I suggest that in cases like this you look at the commit
>
>>> On 01.05.19 at 13:17, wrote:
> We appear to have implemented a memcpy() in the low-memory trampoline
> which we then call into from __start_xen(), for no adequately defined
> reason.
May I suggest that in cases like this you look at the commit
introducing the function? It supplies a reason:
On 01/05/2019 12:17, David Woodhouse wrote:
> From: David Woodhouse
>
> We appear to have implemented a memcpy() in the low-memory trampoline
> which we then call into from __start_xen(), for no adequately defined
> reason.
>
> Kill it with fire.
Absolutely.
> Signed-off-by: David Woodhouse
From: David Woodhouse
We appear to have implemented a memcpy() in the low-memory trampoline
which we then call into from __start_xen(), for no adequately defined
reason.
Kill it with fire.
Signed-off-by: David Woodhouse
---
xen/arch/x86/boot/mem.S| 27 +--
