From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757664AbbCDExN (ORCPT ); Tue, 3 Mar 2015 23:53:13 -0500 Received: from cantor2.suse.de ([195.135.220.15]:36470 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754421AbbCDExL (ORCPT ); Tue, 3 Mar 2015 23:53:11 -0500 Message-ID: <54F68FB0.1040909@suse.com> Date: Wed, 04 Mar 2015 05:53:04 +0100 From: Juergen Gross User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Luis R. Rodriguez" , David Vrabel , Jan Beulich CC: Jeremy Fitzhardinge , Andrey Ryabinin , Rusty Russell , "linux-kernel@vger.kernel.org" , Andy Lutomirski , Chris Wright , xen-devel@lists.xenproject.org, Boris Ostrovsky , virtualization@lists.linux-foundation.org, Alok Kataria Subject: Re: [Xen-devel] kasan_map_early_shadow() on Xen References: <54F587BD.8010606@citrix.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/03/2015 08:20 PM, Luis R. Rodriguez wrote: > On Tue, Mar 3, 2015 at 2:06 AM, David Vrabel wrote: >> On 03/03/15 09:40, Luis R. Rodriguez wrote: >>> Andrey, >>> >>> I believe that on Xen we should disable kasan, would like confirmation >> >> Why? This is the first of heard of this. > > Andrey chimed in here confirming this. > >>> from someone on xen-devel though. Here's the thing though -- if true >>> -- I'd like to do it *properly*, where *properly* means addressing a >>> bit of architecture. A simple Kconfig slap seems rather reactive. I'd >>> like to address a way to properly ensure we don't run into this and >>> other similar issues in the future. The CR4 shadow issue was another >>> recent example issue, also introduced via v4.0 [0]. We can't keep >>> doing this reactively. >>> >>> Let's go down the rabbit hole for a bit. HAVE_ARCH_KASAN will be >>> selected on x86 when: >>> >>> if X86_64 && SPARSEMEM_VMEMMAP >>> >>> Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to enable >> >> Why? Again, this is the first I've heard of this as well. FWIW, all >> the Xen configs we use have SPARSEMEM_VMEMMAP enabled. > > Interesting... we have config ARCH_SPARSEMEM_ENABLE depend on !XEN at > SUSE. Figured this was a generic issue. The SUSE kernels are based on > 3.12 though, but anyway with it enabled I do get compile failures > because of redefinition of MAX_PHYSMEM_BITS which we provide on Xen > set to 43 for some reason (can't find that justification), so it > doesn't use the default 46 that would be used otherwise. But another > reason seems to be the lack of forward porting yet PAT support for PV > domains -- commit 47591df50 upstream which requires us to still have > the union on the pte_t, and I suppose we need ca15f20f as well... > > If there is nothing else I suppose this just requires fixing up at > SUSE's end for SPARSEMEM_VMEMMAP... The SUSE kernel has several patches renaming/altering Xen-related config options. Don't mix that up with upstream/pvops. Juergen