>>> On 02.03.18 at 13:16, <jgr...@suse.com> wrote:
> On 02/03/18 12:23, 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 Xen image and stubs.
>> 
>> Drop the respective code in favor of an explicit clone_mapping()
>> invocation. This in turn now requires setup_cpu_root_pgt() to run after
>> stub setup in all cases. Additionally, with (almost) no unintended
>> mappings left, the BSP's IDT now also needs to be page aligned.
>> 
>> Note that the removed BUILD_BUG_ON()s don't get replaced by anything -
>> there already is a suitable ASSERT() in xen.lds.S.
>> 
>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
> 
> Tested-by: Juergen Gross <jgr...@suse.com>
> Reviewed-by: Juergen Gross <jgr...@suse.com>

Thanks, but I'm afraid there's a minor bug in that change: I need
to free the page tables that the new clone_mapping() may have
produced, but I need to do that without affecting common_pgt.
It may therefore be worthwhile considering to retain the
original approach instead, just doing the changes at L2 rather
than L3. Andrew, do you have a preference either way?

>> ---
>> What should we do with the TSS? Currently together with it we expose
>> almost a full page of other per-CPU data. A simple (but slightly
>> hackish) option would be to use one of the two unused stack slots.
> 
> Either one of the unused stack pages or directly after the GDT (we could
> then drop NR_RESERVED_GDT_PAGES and reduce NR_RESERVED_GDT_ENTRIES to
> a lower value, e.g. 16 or 32).

I dislike moving the TSS into per-domain space. There shouldn't be
anything there that isn't per-domain.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to