linux-kernel - Re: [PATCH] arm/xen: fix SMP guests boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 8 Sep 2016 11:12:13 -0700 (PDT)
From:   Stefano Stabellini <sstabellini@...nel.org>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
cc:     xen-devel@...ts.xenproject.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Russell King <linux@...linux.org.uk>,
        Stefano Stabellini <sstabellini@...nel.org>,
        Julien Grall <julien.grall@....com>,
        Wei Chen <Wei.Chen@....com>,
        David Vrabel <david.vrabel@...rix.com>
Subject: Re: [PATCH] arm/xen: fix SMP guests boot

On Thu, 8 Sep 2016, Vitaly Kuznetsov wrote:
> Commit 88e957d6e47f ("xen: introduce xen_vcpu_id mapping") broke SMP ARM
> guests on Xen. When FIFO-based event channels are in use (this is the
> default), evtchn_fifo_alloc_control_block() is called on CPU_UP_PREPARE
> event and this happens before we set up xen_vcpu_id mapping in
> xen_starting_cpu. Temporary fix the issue by setting direct Linux CPU id
> <-> Xen vCPU id mapping for all possible CPUs at boot. We don't currently
> support kexec/kdump on Xen/ARM so these ids always match.
> 
> In future, we have several ways to solve the issue, e.g.:
> - Eliminate all hypercalls from CPU_UP_PREPARE, do them from the starting
> CPU. This can probably be done for both x86 and ARM and, if done, will
> allow us to get Xen's idea of vCPU id from CPUID/MPIDR on the starting CPU
> directly, no messing with ACPI/device tree required.
> - Save vCPU id information from ACPI/device tree on ARM and use it to
> initialize xen_vcpu_id mapping. This is the same trick we currently do on
> x86.
> 
> Reported-by: Julien Grall <julien.grall@....com>
> Tested-by: Wei Chen <Wei.Chen@....com>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>

Acked-by: Stefano Stabellini <sstabellini@...nel.org>


> It would be nice if this patch could still make it to 4.8 as all SMP
> ARM/Xen guests are currently broken.

Yes


>  arch/arm/xen/enlighten.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 3d2cef6..f193414 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -170,9 +170,6 @@ static int xen_starting_cpu(unsigned int cpu)
>  	pr_info("Xen: initializing cpu%d\n", cpu);
>  	vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
>  
> -	/* Direct vCPU id mapping for ARM guests. */
> -	per_cpu(xen_vcpu_id, cpu) = cpu;
> -
>  	info.mfn = virt_to_gfn(vcpup);
>  	info.offset = xen_offset_in_page(vcpup);
>  
> @@ -330,6 +327,7 @@ static int __init xen_guest_init(void)
>  {
>  	struct xen_add_to_physmap xatp;
>  	struct shared_info *shared_info_page = NULL;
> +	int cpu;
>  
>  	if (!xen_domain())
>  		return 0;
> @@ -380,7 +378,8 @@ static int __init xen_guest_init(void)
>  		return -ENOMEM;
>  
>  	/* Direct vCPU id mapping for ARM guests. */
> -	per_cpu(xen_vcpu_id, 0) = 0;
> +	for_each_possible_cpu(cpu)
> +		per_cpu(xen_vcpu_id, cpu) = cpu;
>  
>  	xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
>  	if (xen_xlate_map_ballooned_pages(&xen_auto_xlat_grant_frames.pfn,
> -- 
> 2.7.4
>