>>> On 02.03.18 at 18:23, wrote:
> On 02/03/18 17:04, Jan Beulich wrote:
> On 02.03.18 at 17:53, wrote:
>>> On 02/03/18 14:34, Jan Beulich wrote:
Note that the removed BUILD_BUG_ON()s don't get replaced by anything -
there already is a suitable ASSERT() in xen.lds.S.
>>> This isn't
On 02/03/18 17:04, Jan Beulich wrote:
On 02.03.18 at 17:53, wrote:
>> On 02/03/18 14:34, Jan Beulich wrote:
>>> Note that the removed BUILD_BUG_ON()s don't get replaced by anything -
>>> there already is a suitable ASSERT() in xen.lds.S.
>> This isn't quite true. You've changed the mechanism
>>> On 02.03.18 at 17:53, wrote:
> On 02/03/18 14:34, Jan Beulich wrote:
>> Note that the removed BUILD_BUG_ON()s don't get replaced by anything -
>> there already is a suitable ASSERT() in xen.lds.S.
>
> This isn't quite true. You've changed the mechanism by which the stubs
> get mapped (from e
On 02/03/18 14:34, Jan Beulich wrote:
> Commit 422588e885 ("x86/xpti: Hide almost all of .text and all
> .data/.rodata/.bss mappings") carefully limited the Xen image cloning to
> just entry code, but then overwrote the just allocated and populated L3
> entry with the normal one again covering both
Commit 422588e885 ("x86/xpti: Hide almost all of .text and all
.data/.rodata/.bss mappings") carefully limited the Xen image cloning to
just entry code, but then overwrote the just allocated and populated L3
entry with the normal one again covering both Xen image and stubs.
Drop the respective cod