|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled
On 15/01/18 11:07, Jan Beulich wrote:
> First of all we don't need it on AMD systems. Additionally allow its use
> to be controlled by command line option. For best backportability, this
> intentionally doesn't use alternative instruction patching to achieve
> the intended effect - while we likely want it, this will be later
> follow-up.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v2: New.
>
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1849,6 +1849,15 @@ In the case that x2apic is in use, this
> clustered mode. The default, given no hint from the **FADT**, is cluster
> mode.
>
> +### xpti
> +> `= <boolean>`
> +
> +> Default: `false` on AMD hardware
> +> Default: `true` everywhere else
This is fine for now, but any further isolation is going to have to be
unconditional, or possibly compile-time choice, but maintaining that
going forwards is going to be truly horrible.
> +
> +Override default selection of whether to isolate 64-bit PV guest page
> +tables.
This wants a
** WARNING: Not yet a complete isolation implementation, but better than
nothing. **
or similar, just to avoid giving the people the impression that it is
complete. Perhaps also a similar warning in the patch 1 commit message?
> +
> ### xsave
> > `= <boolean>`
>
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1511,8 +1511,10 @@ void paravirt_ctxt_switch_to(struct vcpu
> {
> unsigned long cr4;
>
> - this_cpu(root_pgt)[root_table_offset(PERDOMAIN_VIRT_START)] =
> - l4e_from_page(v->domain->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
> + if ( this_cpu(root_pgt) )
> + this_cpu(root_pgt)[root_table_offset(PERDOMAIN_VIRT_START)] =
> + l4e_from_page(v->domain->arch.perdomain_l3_pg,
> + __PAGE_HYPERVISOR_RW);
This would be cleaner and have better generated code by pulling
this_cpu(root_pgt) into a local variable.
>
> cr4 = pv_guest_cr4_to_real_cr4(v);
> if ( unlikely(cr4 != read_cr4()) )
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3685,7 +3685,7 @@ long do_mmu_update(
> rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
> cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
> if ( !rc )
> - sync_guest = true;
> + sync_guest = this_cpu(root_pgt);
This is quite deceptive, as it is actually sync_guest =
this_cpu(root_pgt) != NULL;
It would probably be cleaner to export opt_xpti and use that, rather
than imply things based on root_pgt. It would certainly be more
efficient code.
> break;
>
> case PGT_writable_page:
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -328,7 +328,7 @@ void start_secondary(void *unused)
> spin_debug_disable();
>
> get_cpu_info()->xen_cr3 = 0;
> - get_cpu_info()->pv_cr3 = __pa(this_cpu(root_pgt));
> + get_cpu_info()->pv_cr3 = this_cpu(root_pgt) ? __pa(this_cpu(root_pgt)) :
> 0;
>
> load_system_tables();
>
> @@ -734,14 +734,20 @@ static int clone_mapping(const void *ptr
> return 0;
> }
>
> +static __read_mostly int8_t opt_xpti = -1;
> +boolean_param("xpti", opt_xpti);
> DEFINE_PER_CPU(root_pgentry_t *, root_pgt);
>
> static int setup_cpu_root_pgt(unsigned int cpu)
> {
> - root_pgentry_t *rpt = alloc_xen_pagetable();
> + root_pgentry_t *rpt;
> unsigned int off;
> int rc;
>
> + if ( !opt_xpti )
> + return 0;
> +
> + rpt = alloc_xen_pagetable();
> if ( !rpt )
> return -ENOMEM;
>
> @@ -992,10 +998,13 @@ void __init smp_prepare_cpus(unsigned in
>
> stack_base[0] = stack_start;
>
> + if ( opt_xpti < 0 )
> + opt_xpti = boot_cpu_data.x86_vendor != X86_VENDOR_AMD;
Newline?
> rc = setup_cpu_root_pgt(0);
> if ( rc )
> panic("Error %d setting up PV root page table\n", rc);
> - get_cpu_info()->pv_cr3 = __pa(per_cpu(root_pgt, 0));
> + if ( per_cpu(root_pgt, 0) )
> + get_cpu_info()->pv_cr3 = __pa(per_cpu(root_pgt, 0));
>
> set_nr_sockets();
>
> @@ -1067,6 +1076,7 @@ void __init smp_prepare_boot_cpu(void)
> #endif
>
> get_cpu_info()->xen_cr3 = 0;
> + get_cpu_info()->pv_cr3 = 0;
> }
>
> static void
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -46,6 +46,7 @@ restore_all_guest:
> movabs $DIRECTMAP_VIRT_START, %rcx
> mov %rdi, %rax
> and %rsi, %rdi
> + jz .Lrag_keep_cr3
What is rag? What about .L_skip_cr3_reload ?
~Andrew
> and %r9, %rsi
> add %rcx, %rdi
> add %rcx, %rsi
> @@ -62,6 +63,7 @@ restore_all_guest:
> rep movsq
> mov %r9, STACK_CPUINFO_FIELD(xen_cr3)(%rdx)
> write_cr3 rax, rdi, rsi
> +.Lrag_keep_cr3:
>
> RESTORE_ALL
> testw $TRAP_syscall,4(%rsp)
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |